Multicast mpls communication method

The present invention relates to a multicast MPLS communication method, and in particular, in MPLS forwarding technology, multicast MPLS for forwarding MPLS is performed by guaranteeing QoS efficiently in a network while traffic engineering (TE) the traffic for P2MP communication. Regarding communication method.

Some MPLS signaling protocols have been proposed to the IETF (see, for example, Non-Patent Document 1).<nplcit num="1"><text>RSVP-TE: Extensions to RSVP for LSP Tunnels, RFC3209</text></nplcit>

<p> However, since RSVP-TE is an MPLS signaling protocol that configures P2P LSPs, when attempting to transfer P2MP communication traffic, multiple P2P LSPs are sent to multiple receiving PE nodes that are the destinations of P2MP communication at the sending PE node. With this setting, it will be necessary to copy the receive traffic on the transmit PE node, copy it to the LSP of multiple set P2Ps, and replace it, which will put pressure on the copy performance on the transmit PE node and improve the transfer efficiency of the network. There is a problem of lowering.</p><p> The present invention has been made in view of the above points, and can extend the MPLS signaling protocol of RSVP-TE to copy P2MP multicast at the optimum point in the provider network, resulting in the optimum copy of P2MP multicast for the entire network. The purpose is to provide a possible multicast MPLS communication method.</p>

<p> In the present invention, in a Multiprotocol Label Switching (MPLS) communication network, a provider edge (PE) node located at the boundary of an MPLS network places a point-to-multipoint (P2MP) communication traffic including an IP multicast traffic at a plurality of boundaries. In a multiprotocol MPLS communication method in which MPLS is transferred to the provided provider edge (PE) node, the transmitting PE node uses the MPLS signaling protocol to multiple receiving PE nodes to copypoint to multiple relay nodes in the provider edge (PE). Multiprotocol Label Switching (MPLS) when setting the MPLS forwarding path by installing and setting the P2MP tree-shaped label switching path (LSP) and setting the P2MP tree-shaped label switching path (P2MP LSP). ) P2MP to identify P2MP sessions for P2MP traffic based on the protocol RSVP-TE (RFC3209) To define a P2MP session object consisting of the LSP's transmit PE address and tunnel identifier, as well as the P2MP tunnel identifier, and to explicitly specify the transfer path on the P2MP tree from the transmit PE to multiple receive PEs. Define a tree-shaped object to specify the relay node and branch node on the transfer path of the P2MP LSP, P2MP LSP as the tree-shaped object, and multiple receiving PE nodes from the sending PE of the P2MP LSP to specify the shape. Of these, the point-to-point (P2P) MPLS transfer route to each receiving PE node is specified by the ERO object, which is the P2P transfer route instruction object defined by RSVP-TE (RFC3209), and the entire P2MP LSP is specified. To specify multiple P2P routes from the sending PE node to each receiving PE, specify and define the route of the entire P2MP tree as a P2P route by bundling multiple EROs, and the transmitting PE node specifies the P2MP LSP. When setting, P2MP from the outside Understand the P2MP LSP route to be set by performing the P2MP LSP route calculation to be set between the transmitting PE and multiple receiving PE nodes in cooperation with the LSP route instruction or the traffic engineering extension function of the internal IP routing protocol. When this is done, the tree shape object converts it to the P2MP LSP setting path, and the sending PE node sends the P2MP LSP a common header as a Path message, the defined P2MP session object, RSVP_HOP object, TIME_VALUE object, and the defined P2MP LSP tree topology to be set. A Path message containing a tree-shaped object, LABEL_REQUEST object, SENDER_TEMPLATE object, and SENDER_TSPEC object that specifies information is sent from the sending PE node to the adjacent downstream nodes that make up the P2MP LSP that should be set, and the downstream node that receives the Path message , Its registered Path The State information is searched, and if the Path message is a newly received Path message, the session information is extracted from the Path message, and if the path of the setting request can be set, it is newly registered as PathState information, and then Path. Extract TERO, which is tree shape information to be set as P2MP LSP, from the message, extract ERO information that specifies the explicit transfer route to each receiving PE node of P2MP LSP stored in the TERO, and extract from all ERO information. Extracts all the addresses of the downstream next hop group defined as the next hop of its own node address, extracts the next hop information from each ERO information, and at the same time deletes its own node address from each ERO information, and then the next hop. The ERO information is formatted so that the address is the first stored information of each ERO information, and if there are multiple common next-hop address groups, the modified ERO information that constitutes that group is grouped and the same. Reconstruct the downstream partial tree into the specified partial TERO information, After the above process, for each downstream node corresponding to the next hop, a Path message destined for the downstream node stores the reconstructed TERO information that specifies the partial P2MP LSP under the downstream node, and stores the downstream next hop. Send to the node, repeat the PathState registration process (process 1) and the path message split transmission process (process 2) according to the P2MP LSP route to be set up to the receiving PE node, which is the most downstream leaf node, on the P2MP LSP path. When PathState is registered in the node of, all receiving PE nodes receive the Path message, and the receiving PE node determines that it is a leaf edge node of P2MP LSP, the receiving node is requested P2MP LSP. If can be set, after registering ResvState, the label value used by the receiving node to transfer and receive P2MP traffic from the upstream node is given from the label space of the own node, and the P2MP data in the P2MP LSP. In order to enable forwarding, register the label exchange relationship in the ILM table and NHLFE table, and Furthermore, the receiving node stores its own node address in the RRO object indicating the label value given upstream and the setting route information of P2MP LSP and stores it in the Resv message, and stores it in the upstream PHOP node to which the Path message is transferred. The Resv message is sent immediately, and when the PHOP node receives the Resv message for the first time, the corresponding ResvState is the RRO information that represents the transfer route record of the P2MP LSP set for the downstream node, and the P2MP to the downstream node. Register the information including the label value to be given to the packet when forwarding the traffic, and after registering ResvState, the PHOP node is used to receive the P2MP traffic by label forwarding with the further upstream PHOP node. In order to assign the label value from the label space of the own node and enable P2MP data forwarding in the P2MP LSP, the label exchange relationship is registered in the ILM table and NHLFE table, and the label value assigned upstream and P2MP. Adds its own node address to the tree-based RRO; TRRO that shows the LSP setting route information at the beginning, stores it in the Resv message, and immediately forwards it to the upstream PHOP node as a Resv message. , If you have multiple downstream nodes and receive a Resv message other than the initial Resv message from different downstream nodes of the same P2MPLSP, the configured ResvState information is searched by the session information of the Resv message, and it is already searched. As additional information corresponding to the ResvState information, tree-based RRO information (information including TERO) representing the transfer route record of P2MP LSP set for the corresponding downstream node was additionally registered, and the Resv message was received. When the node determines from the registered ResvState information that the LSP of the upstream PHOP node of the P2MP LSP to be set is set, it identifies the MPLS label given upstream, and further, for the target P2MP LSP. Newly received P2MP for the newly received RESV route In order to enable MPLS forwarding of LSP, the label given upstream to the already set ILM table and NHLFE table is specified from the ILM table, and the RESV received in the NHLFE table which is the entry is specified. The label value for downstream MPLS transfer specified from the message is newly registered as a new entry, and the MPLS label value used for the upstream PHOP node extracted earlier and the setting tree information set under the node are recorded. Therefore, by combining and modifying the tree-based RRO information (TERO information) set under the newly received route and further adding the node address information at the beginning, it is currently under the node. Process the tree-based RRO information that records the already set partial tree information, register the processed tree-based RRO information in the ResvState information, and transfer the already set upstream label. Identify the MPLS label value used for, store it in the Resv message together, and change the state of the tree in which the RESV message is set (new part P2MP). Instantly forwards to the upstream PHOP node to notify (LSP addition), and the node that receives the Resv message registers new ResvState information when the Resv message is received for the first time for the P2MP LSP to be set. Furthermore, at the time of information registration, the tree route information: TERO information is registered in the ResvState information, and the MPLS label used for label transfer with the upstream PHOP is extracted from its own label space, and further, MPLS label transfer is performed. In order to enable this, a new label exchange relationship is registered in the ILM table and NHLFE table of the forwarding part, and the label value used for label transfer with the upstream and its own node address are set in the tree base. The route registration information TRRO is added, the label value and the corrected TRRO information are stored in the Resv message and instantly transferred to the upstream PHOP, and the receiving node is already Resv from another downstream node. Resv processing after receiving the message When the Resv message transmission to the upstream is completed and the partial P2MP LSP is set, the newly set P2MP When a Resv message is received from another downstream route to the LSP, the corresponding ResvState information is specified from the registered ResvState information, and a tree-based tree-based indicating the newly added downstream part P2MP LSP route. RRO information is extracted by Resv message, the already set TRRO information registered in ResvState information is corrected, and the tree-based setting route information TRRO that reflects the additionally set part is changed and registered, and at the same time upstream. Identify the MPLS label attached to the label transfer of, store it in the Resv message at the same time as the TRRO, immediately transfer it to the upstream PHOP node, and set this process on all nodes on the P2MP LSP. Repeated until the Resv message reaches the sending PE node, and when the sending PE node receives the Resv message for the first time for the P2MP LSP to be set, it extracts the label value required for MPLS label transfer downstream from the Resv message. At the same time, the set downstream tree-based route information TRRO is extracted, registered in the ResvState information, and the set P2MP. In order to enable MPLS forwarding for LSP, the label transfer relationship of the FTN table and NHLFE table of the incoming PE is registered, and the sending PE node receives the Resv message for the P2MP LSP to be set from a different downstream node. If so, identify the registered corresponding ResvState information, extract the TRRO information for the newly added downstream partial P2MP LSP, add and modify it to the registered TRRO information, and have already set it at this stage. At the same time as processing and modifying so that it becomes the tree registration information, the label exchange relationship for the partial tree newly added to the FTN table and NTLFE table is added to enable MPLS forwarding, and the sending PE node is used as a Path message. For the set P2MP LSP, if the P2MP label exchange relationship is set for all the nodes that make up the P2MP LSP, from the transmitting PE node to multiple receiving PE nodes using the above MPLS signaling, the received packet Label switching from the transmitting PE node to multiple receiving PE nodes on a P2MP basis according to the P2MP LSP set in After P2MP LSP is established, state maintenance is executed by exchanging Path / Resv messages for periodic refresh between PathState and ResvState between nodes.</p><p> Further, the present invention adds the partial P2MP tree information to be added to the already set tree-based route information TERO when the partial P2MP LSP is set to the already set P2MP LSP in the same manner as the initial tree setting information. Route from the sending PE node that composes the subtree to any receiving leaf PE node in the multiple receiving leaf PE node groups of the subtree, and to the destination of the ERO that is the partial route of the additional P2MP LSP. Add the set {ERO} s as a tree-based TERO (Graft) for partial addition to the already set tree-based TERO, and modify it to the tree-based TERO information that instructs the route of the entire P2MP LSP after addition. However, if only the modified TERO information is changed and stored in the Path message, the sending PE node sends it, and the node that receives the Path message receives the Path message, the above Set the P2MP LSP according to the P2MP LSP setting method, and the node that received the Path message should set the P2MP that the received Path message should set. If it is the second or subsequent Path message for the LSP session, the session information is extracted from the received Path message, and if there is no change in the session information, it shifts to the periodic Path message maintenance state and is extracted. When there is a change in the session information, the Path message is immediately forwarded to the route that should reflect the change in the session information. In particular, regarding the tree-based forwarding route information among the session information, the receiving node sends the Path message. More TERO information is extracted, according to PathState processing, its own node address information is deleted from the {ERO} s information that composes TERO, and the next hop address and subsequent transfer route address information are extracted from each ERO information. The next hop address extracted after that and the transfer route address information after that are stored in the PathState information. The recorded next hop address reflecting the LSP information was compared with the transfer route information after that, and at this time, if a partial P2MP tree part was added in the part downstream from the node, it was extracted from the received Path message. , The next hop address group and subsequent forwarding route addresses include address groups that are not included in the registered recorded next hop address group and subsequent forwarding route address information, so downstream including the new address group. For the transfer route of, group by group via the same downstream node, update the TERO information representing the tree information, store it in the Path message and immediately transfer it to the downstream node, and add a partial P2MP LSP. Further, the downstream portion in which the extracted next hop address and the subsequent transfer route address information and the recorded next hop address and the subsequent transfer route address information are exactly the same is shifted to the route maintenance state.</p><p> Further, the present invention constitutes a partial tree in which the P2MP tree information corresponding to the portion to be deleted from the already set tree-based route information TERO when the partial P2MP LSP is deleted from the already set P2MP is deleted. Of the multiple receive leaf PE node groups in the subtree to be deleted from the send PE node, the ERO corresponding to any receive leaf PE node is a set of {ERO} s that constitutes the tree-based TERO information that has already been set. Delete from, modify to tree-based TERO information that directs the entire P2MP LSP, modify only the modified TERO information of the sending PE node, store it in the Path message, send it, and Path message The node that received the P2MP that the received Path message should set If it is the second or subsequent Path message for the LSP session, the session information is extracted from the received Path message, and if there is no change in the session information, the state shifts to the periodic Path message maintenance state. , If there is a change in the extracted session information, the Path message is immediately forwarded to the route that should reflect the change in the session information, and in particular, among the session information, the tree-based forwarding route information is received. The node extracts the TERO information from the Path message, deletes its own node address information from the {ERO} s information that composes TERO according to the PathState process, and removes the next hop address and the subsequent forwarding address from each ERO information. Information is extracted, and the extracted next hop address and subsequent transfer address information are stored in the PathState information. The next hop address that reflects the LSP information is compared with the transfer route address information after that, and if partial deletion of the partial P2MP tree occurs on the route downstream from the node, it is extracted from the received Path message. Since the next hop address group and the subsequent transfer route address group include the registered next hop address group and the next hop address group that has been deleted from the subsequent transfer route address information, the deleted address is included. For downstream nodes that are present, ERO is grouped for each group that goes through the same downstream node, changed to TERO information that represents tree information, stored in a Path message, and immediately transferred to the downstream node. If the route information is deleted from the next hop information immediately below, the node immediately sends a PathTear message to the downstream transfer route from which the next hop address information is deleted, and the corresponding partial P2MP LSP is deleted. To do.</p><p> Further, the present invention adds the partial P2MP tree information to be added to the already set tree-based route information TERO when the partial P2MP LSP is set to the already set P2MP LSP in the same manner as the initial tree setting information. Route from the sending PE node that composes the subtree to the destination of the ERO that is the subroute of the additional P2MP LSP by instructing the route by ERO to any receiving leaf PE node among multiple receiving leaf PE node groups in the subtree. Add the set {ERO} s of to the already set tree-based TERO as a tree-based TERO (Graft) for partial addition, and add it to the tree-based TERO information that directs the entire P2MP LSP after addition. If the received Path message is a new Path message, the node that modified it, changed only the corrected TERO information, stored it in the Path message, sent it by the sending PE node, and received the Path message , Set the P2MP LSP according to the above P2MP LSP setting method, and the node that received the Path message should set the P2MP that the received Path message should set. If it is the second or subsequent Path message for the LSP session, the session information is extracted from the received Path message, and if there is no change in the session information, it shifts to the periodic Path message maintenance state. When there is a change in the extracted session information, the Path message is immediately forwarded to the route that should reflect the change in the session information, and in particular, for the tree-based forwarding route information among the session information, the receiving node is Path. Extract TERO information from the message, delete its own node address information from the {ERO} s information that composes TERO according to PathState processing, and extract the next hop address and subsequent transfer route address information from each ERO information. Then, the next hop address extracted after that and the transfer route address information after that are stored in the PathState information. The recorded next hop address reflecting the LSP information was compared with the transfer route information after that, and at this time, if a partial P2MP tree part was added in the part downstream from the node, it was extracted from the received Path message. , The next hop address group and subsequent forwarding route addresses include address groups that are not included in the registered recorded next hop address group and subsequent forwarding route address information, so downstream including the new address group. For the transfer route of, group by group via the same downstream node, update the TERO information representing the tree information, store it in the Path message and immediately transfer to the downstream node, additional setting of partial P2MPLSP And further, for the downstream part where the extracted next hop address and the subsequent transfer route address information and the recorded next hop address and the subsequent transfer route address information are exactly the same, additional processing to shift to the route maintenance state. And from the already set P2MP to the partial P2MP When deleting an LSP, the P2MP tree information corresponding to the part to be deleted from the already set tree-based route information TERO is deleted from the sending PE nodes that make up the partial tree to be deleted. Multiple receiving leaves of the partial tree. A tree that directs the entire P2MP LSP by deleting the ERO corresponding to any receiving leaf PE node in the PE node group from the {ERO} s set that constitutes the already set tree-based TERO information. The TERO information is modified to the base TERO information, and the sending PE node modifies only the modified TERO information, stores it in the Path message, sends it, and the node that receives the Path message is the P2MP that the received Path message should set. If it is the second or subsequent Path message for the LSP session, the session information is extracted from the received Path message, and if there is no change in the session information, the state shifts to the periodic Path message maintenance state. However, if there is a change in the extracted session information, the Path message is immediately forwarded to the route that should reflect the change in the session information, and in particular, among the session information, the tree-based transfer route information is used. The receiving node extracts the TERO information from the Path message, deletes its own node address information from the {ERO} s information that composes TERO according to the PathState process, and transfers the next hop address and subsequent hop addresses from each ERO information. Preconfigured P2MP that extracts address information and stores the extracted next hop address and subsequent transfer address information in PathState information. The recorded next hop address that reflects the LSP information is compared with the transfer route address information after that, and at this time, if partial deletion of the partial P2MP tree occurs in the route downstream from the node, it is extracted from the received Path message. Since the next hop address group and the subsequent transfer route address group include the registered next hop address group and the next hop address group deleted from the subsequent transfer route address information, the deleted address is concerned. For downstream nodes that include, ERO is grouped for each group that goes through the same downstream node, changed to TERO information that represents tree information, stored in a Path message, and immediately transferred to the downstream node. If the route information is deleted from the next hop information directly under the node, the node immediately sends a PathTear message to the downstream transfer route from which the next hop address information is deleted, and the corresponding partial P2MP LSP. The deletion process for deleting the node is performed at the same time.</p><p> Further, according to the present invention, when the intermediate node receiving the Path message identifies the next hop information from the TERO information included in the Path message, the next hop information includes the address information specified as Loose. Loose Performs P2MP tree-based LSP extension for the specified address group.</p><p> Further, according to the present invention, when a P2MP LSP having a P2MP LSP identifier is set and a plurality of P2MP LSPs having different receiving PE node groups are set using the same P2MP LSP identifier, the P2MP of a plurality of different P2MP LSPs is set. Share the P2MP LSP using a common MPLS transfer label in the part that shares the transfer path.</p><p> Further, in the present invention, when the P2MP LSP is set, the LSP is set using the SE reservation style of RSVP, and the P2MP sharing route is SE-shared.</p>

<p> The present invention sets TERO for the P2MP LSP tree-based route information that should be specified in the RSVP-TE Path message when setting the multicast label switching route, and the Path message is in the network according to the tree-based route information. The main feature is that the transfer route of P2MP LSP and the copy branch point in the network can be easily designed by describing the P2MP route to be set in TERO. The conventional technology is that not only P2P LSP but also P2MP LSP can be set by traffic engineering by any transfer path using the same protocol. Not only P2MP but also P2MP and P2P LSP can be set at the same time. The points that can be done are very different.</p><p> Furthermore, as a second feature, since the tree-based route information is composed of ERO, which is the P2P MPLS routing information, the entire tree is transmitted from the transmitting PE when specifying the tree shape of the P2MP LSP to be set. Since it can be specified as a superposition of P2P routes to the receiving leaf PE, it enables intuitive route specification, and when a Path message holding TERO sets P2MP LSP in the network, TERO at the LSP branch point. Is defined as a set of EROs, so P2MP can be easily extended using existing P2P RSVP-TE implementation assets.</p><p> Furthermore, as a third feature, when setting P2MP LSP, multiple P2MP LSPs with different physical topologies are set in order to set P2MP LSP while retaining the P2MP LSP-id information that identifies the P2MP LSP in the session information. If you set the same P2MP LSP-id, you can combine multiple P2MP LSPs as the same P2MP LSP.</p>

Hereinafter, embodiments of the present invention will be described with reference to the drawings.

[First Embodiment]

As a first embodiment, an example of multicast label switching will be described.

The communication route setting method and packet transfer mechanism for multicast label switching will be described below.

FIG. 1 shows a P2MP session object according to the first embodiment of the present invention.

When setting the LSP of P2MP, use the tunnel identifier and the sender address of the tunnel as the P2M session. Figure 1 shows an IPv4 P2MP session object. As shown in Figure 1, the P2MP session object also contains the P2MPTunnelID information needed to combine different P2MP LSPs.

This P2MPTunnelID shares different P2MPLSPs when the sending PE node is shared and the forwarding path from the sending PE node to the destination receiving PE leaf node is shared by multiple different P2MPLSPs with different destination receiving leaf nodes. common P2MP communication bets with when transferring Rahikku is effective when used to combine different P2MPLSP to one P2MPLSP.

FIG. 2 shows a tree-based TERO information element in the first embodiment of the present invention. In the example of FIG. 2, the P2MP transfer path from the transmitting PE node A to the four receiving PE nodes G, F, C, and D is shown. This TERO information can be expressed as a superposition of different P2P transfer paths. For example, in the case of Fig. 2, the transfer route from the transmitting PE node A to the receiving PE leaf node G is P2P route 1: {A, B, E, G}, and how is the receiving PE leaf from the transmitting PE node A? The transfer route to node F is P2P route 2: {A, B, E, F}, and similarly, the transfer route from transmission PE node A to reception PE leaf node D is P2P route 3: {A, B, D}. Similarly, the transfer route from the transmission PE node A to the reception PE leaf node C can be expressed by P2P route 4: {A, B, C}. Therefore, the tree-based transfer route information TERO, which is the P2MP transfer route in FIG. 2, can be expressed as a set of EROs, which are P2P transfer route information, and TERO = {ER01 (A, B, E, G), ERO2 ( It can be expressed as A, B, E, F), ERO3 (A, B, D), ERO4 (A, B, C)}.

Next, the Path message and the Resv message used in the present invention will be described. The Path message is &lt;Path Message&gt; :: = &lt;Common Header&gt; [&lt;INTEGITY&gt;]

[[&lt;MESSAGE_ID_ACK&gt; | &lt;MESSAGE_ID_NACK&gt;] ...]

[&lt;MESSAGE_ID&gt;] &lt;SESSION&gt; &lt;RSVP_HOP&gt; &lt;TIME_VALUES&gt; &lt;TREE_EXPLICIT_ROUTE&gt; &lt;LABEL_REQUEST&gt; [&lt;PROTECTION&gt;]

[&lt;LABEL_SET&gt;] [&lt;SESSION_ATTRIBUTE&gt;]

[&lt;NOTIFY_REQUEST&gt;] [&lt;ADMIN_STATUS&gt;]

[&lt;POLICY_DATA&gt; ...] &lt;sender descriptor&gt; &lt;sender descriptor&gt; :: &lt;SENDER_TEMPLATE&gt; Expressed in &lt;SENDER_TSPEC&gt; format. Note that the major difference from the conventional P2P RSVT-TE is that the SESSION object format and TERO object format are different as described above. Also, the Resv message is &lt;Resv Message&gt; :: = &lt;Common Header&gt; [&lt;INTEGRITY&gt;]

[[&lt;MESSAGE_ID_ACK&gt; | &lt;MESSAGE_ID_NACK&gt;] ...]

[&lt;MESSAGE_ID&gt;] &lt;SESSION&gt; &lt;RSVP_HOP&gt; &lt;TIME_VALUES&gt; [&lt;RESV_CONFIRM&gt;] [&lt;SCOPE&gt;]

[&lt;NOTIFY_REQUEST&gt;] [&lt;ADMIN_STATUS&gt;]

[&lt;POLICY_DATA&gt; ...] &lt;STYLE&gt; &lt;flow descriptor list&gt; &lt;flow descriptor list&gt; :: = &lt;FF flow descriptor list&gt; | &lt;SE flow descriptor&gt; &lt;FF flow descriptor list&gt; :: = &lt;FLOWSPEC&gt; &lt;FILTER_SPEC &gt; &lt;LABEL&gt; [&lt;TREE_RECORD_ROUTE&gt;]

| &lt;FF flow descriptor list&gt; &lt;FF flow descriptor&gt; &lt;FF flow descriptor&gt; :: = [&lt;FLOWSPEC&gt;] &lt;FILTER_SPEC&gt; &lt;LABEL&gt; [&lt;TREE_RECORD_ROUTE&gt;]

&lt;SE flow descriptor&gt; :: =, FLOWSPEC&gt; &lt;SE filter spec list&gt; &lt;SE filter spec list&gt; :: = &lt;SE filter spec&gt; | &lt;SE filter spec list&gt; &lt;SE filter spec&gt; &lt;SE filter spec&gt; :: = Expressed in the format &lt;FILTER_SPEC&gt; &lt;LABEL&gt; [&lt;TREE_RECORD_ROUTE&gt;. Note that the major difference from the conventional P2P RSVP-TE is that the TRRO object format is different along with the SESSION object.

Next, the basic setting mechanism of P2MPLSP will be described with reference to FIGS. 3 and 4. Figure 3 shows an example of setting P2MPLSP up to C, D, F, and C where the transmitting PE node is the receiving PE leaf node. The set P2MPLSP follows the transfer path shown in Fig. 2. When the transmission PE node A determines the transfer route of P2MPLSP to be set, the transmission PE node A stores the transfer route information in the tree-based transfer route information TERO object. In this example, TERO = {ERO (A, B, C), ERO (A, B, D), ERO (A, B, E, F), ERO (A, B, E, G)} There is. In addition, the sending PE node stores the P2MPLSP TunnelID and P2MPTunnelID to be set in the SESSION object. At the same time, specify the LSP ID with SENDER TEMPLATE. At the same time, specify the LSPID with SENDER TEMPLATE.

After this, the sending PE node A stores the · Common Header; · SESSION; · RSVP_HOP · TIME_VALUE; · TERO; · LABEL_REQUEST; · SENDER_TEMPULATE; · SENDER_TSPEC: · RECOD_ROUTE object shown above in the Path message and downstream. Send to node B. When the node B that receives the Path message searches the PathState information and determines that the P2MP session is a new P2MP session, the PathState has session information of, SESSION, RSVP_HOP, TERO, LABEL_REQUEST, SENDER_TEMPULATE, and so on. Register information as a SENDER_TSPEC / RECORD_ROUTE object. At this time, node B simultaneously determines whether the P2MPLSP of the path setting request can be set in the node, and if it can be set, tree-based the next hop in order to forward the Path message to the downstream node. Specified from the TERO object of.

First, the ERO information included in the TERO information is taken out, its own node address number is deleted from the hop information, and the next hop address to each leaf is specified. In the example of Figure 3, the next hop to leaf C is node C, the next hop to leaf D is node D, the next hop to leaf F is node E, and the next hop to leaf G is node E. Identify that.

Furthermore, if all the next hops are strict specified, node B modifies the ERO set for each downstream P2MP subtree from the specified next hop to a tree-based TERO that specifies the downstream subtree. .. In the case of Fig. 3, ERO (C) becomes TERO information up to leaf C because the tree exists only up to leaf C, and similarly, ERO (D) becomes TERO information up to leaf D up to leaf D. Since leaf F and leaf G have the same next hop address E, the same downstream subtree can be configured. Therefore, as tree-based TERO information, TERO = {ERO (E, F), ERO together. It is formatted as (E, G)}.

After this processing, node B stores the previously modified TERO information and transfers it to the downstream node with the same Path message information toward each downstream subtree (except for SESSION and TERO, which are omitted in FIG. 3).

In the example of FIG. 3, Path (..., SESSION, ... TERO {ERO (E, F), ERO (E, G)} ...) is sent to the downstream node E. After that, the same operation is repeated on node E, and Path messages are sent to leaf nodes F and G.

When the P2MPLSP can be set, the leaf nodes C, D, F, and G that have received the Path message confirm the ResvState information and send the Resv message of the P2MPLSP reservation confirmation message to the upstream PHOP node. At this time, the downstream leaf node determines the label value used when the upstream PHOP node transfers the label of P2MP traffic to and from the node from its own label space, stores the Resv message, and transfers it. In the example of FIG. 4, a label value of 51,105 is assigned for label transfer between node B and nodes C and D, and a label value of 10,23 is assigned for label transfer between node E and nodes F and G. An example is shown. When a Resv message is sent from the downstream and the upstream node receives the Resv message, the ResvState information is registered by the Resv message. FIG. 4 shows an example in which node B first receives Resv messages from nodes C and D at the same time.

Node B extracts and stores the information required for ResvState information from the received Resv message. At this time, note that the downstream node holds the tree-based TERO information that records the P2MPLSP setting route. Since the P2MPLSP leaf is confirmed from node C, the information of TERO {RRO (C)} is notified.

The information components of TERO are recorded as a set of RRO objects, which are P2P route recording objects, like TERO information. Similarly, leaf node D notifies the information of TRRO = {RRO (D)}.

When the node B that receives these Resv messages can set the P2MPLSP further upstream, it assigns the label value to be used with the upstream node A from its own label space. In the example of FIG. 4, a label value of 200 is given. At the same time as this label is assigned, node B records and registers the label exchange relationship with the downstream node; input label 200 output label 1:51 and output label 2: 105 in the ILM table and NHLFE table. At the same time, register the label exchange relation of the forwarding part. Also, at this time, node B has received two Resv messages, so the information is merged. Since the parts other than the path setting record information are common, TRRO is merged, first, the own node address information is added to the head header, and in the example of Fig. 4, the routes (B, C) and (B,) to the two leaves Since D) is merged, the tree-based route recording information is TERRO = {RRO (B, C), RRO (B, D)}.

This merged TRRO information and the label value used with the upstream node given earlier are stored in the Resv message and immediately transferred to the upstream node. In the example of FIG. 4, such an operation is also performed between the nodes E, F, and G, and the merged Resv message arrives at the node B with a slight delay from the node E.

The node B that has received this merged Resv message determines from the session information that the Resv message is a Resv message related to the P2MPLSP that has already been set by searching the ResvState information. Node B adds the label exchange relations of the ILM table and NHLFE table that have already been set; input label 200 output label 1:51, output label 2: 105 and the newly received downstream label value; 505. Corrected label exchange relationship; Input label 200 Output label 1:51, Output label 2: 105, Output label 3: 505 are additionally registered. At the same time as this operation, add the setting tree information TRRO = {RRO (E, F), RRO (E, G)} received from the downstream to the ResvState information that is recorded.

The added TRRO information indicates the current setting subtree information, so TRRO = {ERO (B, E, F), RRO (B, E, G) RRO (B, C), RRO (B, D) }.

After the end of this operation, node B stores the same label value previously given to the Resv message: 200 and the actually modified RRRO information to notify upstream immediately of the change in LSP state, and node A upstream. Immediately notify the Resv message.

In this way, the sending node A determines the tree-based setting route information in the stored Resv message by receiving the two Resv messages from the downstream node, and the P2MPLSP requested to be set is completely set. To judge. By such processing, as shown in Fig. 4, node A (200) node B (51) node C (105) node D (505) node E (10) for the setting P2MPLSP. Node F (23) Node G label exchange relation is set, and P2MP label switching becomes possible.

[Second Embodiment]

In this embodiment, an example of multicast MPaS Grafting will be described.

The Grafting mechanism, which is an additional process of the partial P2MPLSP of the present invention, will be described with reference to the examples of FIGS. 5 and 6.

In the example of FIG. 5, an example of Grafting the leaf LSP: EH up to the node H under the node E is shown for the already set tree.

Leaf LSP: The sending PE node A for Grafting the EH adds the designated route ERO = (A, B, E, H) to the additional receiving leaf H to the configured tree-based routing information TERO. The sending PE node A includes the P2MP session information already set as the Path message, and includes the new ERO information of the addition / correction part in the TERO information.

Upon receiving the Path message, the node B searches its own PathState information and determines whether the Path message is for a new P2MPLSP setting or for an already set P2MPLSP. In the case of FIG. 5, it is a Path message for P2MPLSP setting that has already been set, and when this is determined, it is determined whether or not the Path request information contains information that has already been set and is different from the information that has already been set. In this case, since the ERO (B, E, H) route that is not registered as TERO information is specified, node B determines that it is a Grafting processing request for the same already set P2MPLSP. ERO (B, E, H) information for this new Grafting is newly added to the PathState information.

At the same time as this processing, the same downstream next hop is provided in order to instantly execute the downstream Grafting processing. ERO (E, F), ERO (E, G), ERO (E, H) are modified to tree-based TERO information and stored in the Path message to the downstream node E for notification. At this time, note that the trigger Path message is not sent because there is no state change request for the subtrees BC and BD under node B. For this downstream node, Path / Resv message exchange for refreshing based on normal Path / Resv state retention is performed.

Node E that received the path message of the trigger similarly compares the registered PathState information and the received Path message, and determines that this Path message is a Grafting processing request for Leaf H, so that it is directed to Leaf H. Sends the trigger Path message. At this time, note that the leaf F and G are still in the normal refresh state and the trigger Path message is not sent. At this time, if the Grafting request can be made and the leaf LSP can be set, the leaf node H is given a label value to be used between E and H and Resv is given to the upstream node E as shown in FIG. Send a message. At this time, node E recognizes the downstream change by comparing the registered ResvState information with the received Resv message. Therefore, the TRRO information in the downstream setting tree information of ResvState is updated and the label already assigned to the upstream is updated. It is stored in the Resv message together with the value and notified upstream as the Resv message and trigger message.

In the example of FIG. 6, the processing operation of the node B that has received this trigger Resv message is described. Node B receives the subtree change information under E as TRRO = {RRO (E, F), RRO (E, G), RRO (E, H)}, so it adds its own node address to the header information. Then, register as TRRO = {RRO (B, C), RRO (B, D) RRO (B, E, F), RRO (B, E, G), RRO (B, E, H)} in the ResvState information. At the same time, it is stored in the Resv message and notified to the upstream node A as a trigger message.

When node A receives this Resv message, the Grafting process is completed.

[Third Embodiment]

In this embodiment, the Pruning process of multicast MPLS will be described.

In the following, it will be described with reference to FIGS. 7 and 8. The example shown in Fig. 7 shows an example of pruning leaf LSP: EH from under node E of the P2MP LSP that has already been set.

The sending PE node A deletes TERO = {ERO (A, B, E, H)}, which is the subtree information for the leaf to be deleted, from the TERO representing the tree-based route setting information of the P2MPLSP that has already been set.

Node A sends a Path message containing the deleted and modified TERO information to the P2MPLSP that has already been set.

The node B that has received the Path message searches for the corresponding Path information from the PathState information that has already been registered, compares it with the received Path message information, and checks whether there is a correction request condition. In the case of this example, node B detects that the ERO (B, E, H) information registered in the PathState information has been deleted from the TERO information, so it is a Pruning process request for leaf H. Judge and remove ERO (B, E, H) from its registration, and at the same time modify TERO = {ERO (E, F), ERO (E, Send G)}.

At this time, since there is no change request for nodes C and D under node B, it should be noted that the normal Path / Resv refresh state is maintained. Node E, which receives the modified Path message of the trigger, also determines its own PathState registration information, and if it determines that it is a Pruning processing request for Leaf EH, it determines its own ERO = (E, H) information as PathState. Send a PathTear message as a trigger message to remove from the information and remove the LSP on the leaf EH.

This trigger PathTear message deletes the leaf LSP: EH under node E. At the same time as this deletion, node E also updates its own ResvState information as shown in Fig. 8, and sends a Resv message containing the changed P2MPLSP information upstream as a trigger message to notify the P2MPLSP change status upstream. ..

In the example of FIG. 8, since the LSP of the leaf EH has been deleted, the Resv message holding TRRO = {RRO (E, F), RRO (E, G)} is sent upstream as a trigger message.

Further, the node B that has received the Resv message updates its own ResvState information, and at the same time, stores the change in the Resv message and notifies the upstream node A of the change. In this way, the pruning process is completed when the node A receives the change of the subtree by the notification of the Resv message.

[Fourth Embodiment]

In this embodiment, the P2MPLSP coupling process of multicast MPLS will be described.

Figure 9 shows an example in which P2MPLSPs with different topologies are set from the same transmitting PE node A. At this time, the Tunnel ID of the P2MPLSP heading for the leaves C and D and the TunnelID of the P2MPLSP heading for the leaves E and G are set with different IDs, but the P2MPTunnelID is processed with the same ID.

The two P2MPLSPs share the tree path AB. In this example, it is assumed that P2MPLSP for leaf C and D is set first. In this case, it is determined that the control part of the node has the same P2MPTunnelID at the time of signaling the P2MP LSP setting for leaves F and G, and node B assigns a label value between A and B to confirm the LSP reservation. Occasionally, the data planes of two P2MP LSPs can be combined by assigning the label values set to the LSPs of leaves C and D earlier.

Further, the present invention has an advantage that the existing P2P mechanism can be applied in the merging process by combining the data planes and filtering the Resv message when the reservation style of both P2MPLSPs is the SE reservation style.

[Fifth Embodiment]

In the present embodiment, when the intermediate node specifies the next hop address information from the TERO information when the P2MP LSP is set, the LSP can be extended to a plurality of next hop address nodes with a plurality of Loose hops specified on a P2MP tree basis.

The present invention is not limited to the above-described embodiment, and various modifications and applications can be made within the scope of the claims.

The present invention is applicable to MPLS communication protocol technology for setting a multicast MPLS forwarding route and its systemization technology.

<figref num="1">It is a figure which shows the P2MP session object in 1st Embodiment of this invention.</figref><figref num="2">It is a figure which shows the tree-based TERO information element in the 1st Embodiment of this invention.</figref><figref num="3">It is a sequence diagram of the Path message which sets P2MPLSP in the 1st Embodiment of this invention.</figref><figref num="4">It is a sequence diagram of the Resv message which sets P2MP in the 1st Embodiment of this invention.</figref><figref num="5">It is a sequence diagram of the Path message of the P2MPLSP additional processing in the 2nd Embodiment of this invention.</figref><figref num="6">It is a sequence diagram of the Resv message of the additional processing of P2MPLSP in the second embodiment of the present invention.</figref><figref num="7">It is a sequence diagram of the Path message of the deletion process of P2MPLSP in the third embodiment of the present invention.</figref><figref num="8">It is a sequence diagram of the Resv message of the deletion process of P2MPLSP in the third embodiment of the present invention.</figref><figref num="9">It is a figure which shows the binding process of P2MPLSP in the 4th Embodiment of this invention.</figref>