Network Working Group Shuying Liu Internet Draft Gang Cheng Expires: August 30, 2006 Lianshu Zheng Huawei Technologies February 24, 2006 Reroute Extensions to LDP for P2MP LSP draft-liu-mpls-ldp-p2mp-reroute-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 30, 2006. Abstract This document describes some extensions to the Label Distribution Protocol (LDP) for the reroute of point to multi-point (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. The solution relies on LDP only and has no requirement of a multicast routing protocol in the network. Protocol elements and procedures for this solution are described for rerouting a P2MP LSP in the following cases:1)network failure (link or node); 2)a better path emerges (e.g. new link available, metric change);3)planned maintenance. The rerouting mechanism described in this document can minimize the time of traffic disruption when network failure happens. It will also minimize the data duplication and guarantee the traffic Liu Expires August 24, 2006 [Page 1] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 continuity during the procedure of rerouting in the last two cases mentioned above. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. Table of Contents 1. Terminology..................................................3 2. Introduction.................................................3 3. Local repair techniques for a P2MP LSP in case of network failure........................................................4 3.1. Technique to find the downstream adjoining LSR of a failed link or a failed LSR..................................5 3.2. Technique to rebuild the LSP from the downstream adjoining LSR to the root LSR................................5 3.3. An example of local repair..............................5 4. Rebuilding a non-shortest P2MP LSP into the shortest P2MP LSP6 4.1. LDP Extensions..........................................7 4.1.1. Path Check message.................................7 4.1.2. Path Modify message................................8 4.1.3. Path_Modify_Flag..................................10 4.2. The operations of Path Check message...................10 4.2.1. Root LSR operation................................11 4.2.2. Transit LSR operation.............................11 4.2.3. Leaf LSR operation................................11 4.3. The operations of Path Modify message..................12 4.3.1. Leaf LSR operation................................12 4.3.2. Transit LSR operation.............................13 4.3.3. Root LSR operation................................13 4.4. An example of rebuilding one P2MP LSP..................14 5. Installing multicast forwarding state to LFIB...............15 6. Special operations during local repairing and rebuilding P2MP LSP...........................................................16 7. Security Considerations.....................................17 8. IANA Considerations.........................................17 9. Acknowledgments.............................................17 10. References.................................................18 10.1. Normative References..................................18 10.2. Informative References................................18 Author's Addresses.............................................19 Intellectual Property Statement................................19 Liu Expires August 30, 2006 [Page 2] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 Disclaimer of Validity........................................19 Copyright Statement...........................................19 Acknowledgment................................................20 1. Terminology LSR: Label Switching Router LSP: MPLS Label Switched Path Ingress LSR: Router acting as a sender of a LSP Egress LSR: Router acting as a receiver of a LSP P2P LSP: A LSP that has one unique Ingress LSR and one unique Egress LSR MP2P LSP: A LSP that has one or more Ingress LSRs and one unique Egress LSR P2MP LSP: A LSP that has one unique Ingress LSR and one or more Egress LSRs Leaf LSR: Egress LSR of a P2MP LSP Transit LSR: A LSR of a P2MP LSP that has one or more downstream LSRs Branch LSR: A LSR of a P2MP LSP that has more than one downstream LSR Bud LSR: A LSR of a P2MP LSP that is an egress but also has one or more directly connected downstream LSRs ILM: Incoming Label Map LFIB: label forwarding information base 2. Introduction The LDP protocol is described in [2]. It defines the mechanisms for setting up point-to-point (P2P) and multipoint-to-point (MP2P) LSPs in MPLS networks. There are emerging requirements for supporting delivery of point-to-multipoint applications in MPLS networks, such as those defined in [4] and [5]. An extension has been made to LDP for setting up point-to-multipoint (P2MP) and multipoint-to-multipoint(MP2MP) LSPs in [6], the extension rely upon the unicast routing information. In [6], there is a basic Liu Expires August 30, 2006 [Page 3] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 rerouting mechanism for P2MP LSP and MP2MP LSP when unicast routing information changes in the following cases:1)network failure; 2)a better path emerges;3)planned maintenance. But an issue exists: When a large number of P2MP LSPs exists in MPLS networks, if unicast routing information changes, there would be many LSRs whose upstream LSRs have changed in every P2MP LSP. Each of them sends a Label Withdraw message to its old upstream LSR and a Label Map message to its new upstream LSR at the same time for rebuilding the P2MP LSP where it participates in. As a result, the load of every LSR will increase sharply and the time of traffic disruption in every P2MP LSP will last for a long time. The lost of packets will also occur. Because of the foregoing reasons, the multicast services can not scale well in MPLS networks. To cope with the problem expatiated above, this document proposes another mechanism for the reroute of P2MP LSPs in MPLS networks. The rerouting mechanism described in this document can minimize the time of traffic disruption when network failure happens. It will also minimize the data duplication and guarantee the traffic continuity during the procedure of rerouting in case of a better path emerging and planned maintenance. Section 3 describes local repair techniques for a P2MP LSP in case of network failure (link or node). Section 4 describes the LDP protocol extensions to support rebuilding a non-shortest P2MP LSP into the shortest P2MP LSP in case of a better path emerging and planned maintenance. Section 5 addresses the process of installing a multicast forwarding state into LFIB (label forwarding information base) driven by unknown multicast packets. Section 6 finally discusses special operations during local repairing in section 3 and rebuilding a P2MP LSP in section 4. The methods and procedures discussed in this document depend upon one assumption: when unicast routing information changes, every LSR in MPLS networks will check the type of every forwarding state on itself. For a multicast forwarding state, it will not be updated when the unicast routing information changes. For a unicast forwarding state, it will be updated with the change of unicast routing information. 3. Local repair techniques for a P2MP LSP in case of network failure When a link or a LSR in a P2MP LSP fails, two local repair techniques are proposed to repair the disconnected P2MP LSP: one is used to find the downstream adjoining LSR of the failed link or the failed LSR in the P2MP LSP, another is used to rebuild the LSP from the downstream adjoining LSR of the failed link or the failed LSR to the root LSR. Liu Expires August 30, 2006 [Page 4] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 3.1. Technique to find the downstream adjoining LSR of a failed link or a failed LSR When a link in a P2MP LSP fails, all adjoining LSRs of the failed link can sense the failure, including the downstream adjoining LSR and the upstream adjoining LSR. Every adjoining LSR will check its interface which the failed link attaches to, if the interface is the current incoming interface of the multicast forwarding state, this adjoining LSR is then the downstream adjoining LSR of the failed link in the P2MP LSP, otherwise this adjoining LSR is not the downstream adjoining LSR of the failed link in the P2MP LSP. The corresponding technique for a failed link attached to an Ethernet LAN interface is outside the scope of this document. When a LSR in a P2MP LSP fails, all adjoining LSRs of the failed LSR can find the failure, including the downstream adjoining LSRs and the upstream adjoining LSRs. Every adjoining LSR will check the outgoing interface of next hop to the failed LSR, if the interface is the current incoming interface of the multicast forwarding state, this adjoining LSR is then the downstream adjoining LSR of the failed LSR in the P2MP LSP, otherwise this adjoining LSR is not the downstream adjoining LSR of the failed LSR in the P2MP LSP. The corresponding technique for a failed LSR within an Ethernet LAN is outside the scope of this document. 3.2. Technique to rebuild the LSP from the downstream adjoining LSR to the root LSR After the downstream adjoining LSR of a failed link/LSR is found in a P2MP LSP, it begins to rebuild the LSP from itself to the root LSR. The downstream adjoining LSR assigns a label, and sends a P2MP Label Map message to its upstream LSR along the best path from itself to the root LSR. The LSR which receives the P2MP Label Map message later will also assign a label, and send a P2MP Label Map message to its upstream LSR again. This process will be repeated step by step until the LSP to root LSR is rebuilt. When the downstream adjoining LSR of the failed link/LSR can not find the next hop to the root LSR, it will send a label release message to its downstream LSR along P2MP LSP to release the sub P2MP LSP which can not forward multicast traffic because of network failure. 3.3. An example of local repair This section presents an example of local repair techniques for a P2MP LSP in case of network failure. Liu Expires August 30, 2006 [Page 5] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 [R3]--------[R5]---receiver1 / \ / source--[R1] [R4] \ / \ [R2] [R6]---receiver2 the metric of R1->R2: 5 ; the metric of R1->R3: 5 the metric of R2->R4: 5 ; the metric of R3->R4: 20 the metric of R4->R5: 5 ; the metric of R4->R6: 5 the metric of R3->R5: 16 figure 1: an example of local repair In figure 1, there are six LSRs: R1, R2, R3, R4, R5 and R6. R1 is root LSR, R5 and R6 are leaf LSRs. Along the best path from leaf LSRs to the root LSR, two LSPs have been built i.e. R1->R2->R4->R5 and R1- >R2->R4->R6. When R2 fails, its adjoining LSRs in the P2MP LSP are R1 and R4. For R4, because the outgoing interface of next hop to R2 is the incoming interface of the multicast forwarding state for the P2MP LSP, so R4 is the downstream adjoining LSR of R2 in the P2MP LSP. LSRs including R1, R3, R4, R5 and R6 will not update their multicast forwarding state with changes of unicast routing information. R4 assigns a label, and sends a P2MP Label Map message to R3. After receiving the P2MP Label Map message from R4, R3 also assigns a label, and sends a P2MP Label Map message to R1. At last, the LSP from R4 to R1 is rebuilt, and there are two new LSPs: R1->R3->R4->R5 and R1->R3- >R4->R6. 4. Rebuilding a non-shortest P2MP LSP into the shortest P2MP LSP In case of network failure, after the P2MP LSP is rebuilt using the local repair techniques mentioned above, it is possibly not the shortest P2MP LSP. In case of a better path emerging and planned maintenance, with the changes of unicast routing information, a P2MP LSP may become a non-shortest P2MP LSP as well. To rebuild a non- shortest P2MP LSP into the shortest P2MP LSP, this document introduces two additional messages and some procedures for the two messages to the Label Distribution Protocol (LDP), and adds a flag to multicast forwarding state. Liu Expires August 30, 2006 [Page 6] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 4.1. LDP Extensions There are three extensions to the Label Distribution Protocol (LDP), including Path Check message Path Modify message and Path_Modify_Flag. 4.1.1. Path Check message A Path Check message is used to verify that whether all the LSPs from root LSR to every leaf LSR are the shortest LSPs. The Path Check message is created by root LSR and sent to every leaf LSR along the P2MP LSP. Every Transit LSR will have some operations after receiving a Path Check message. The Path Check message mainly consists of a P2MP FEC TLV and a PATH STATUS TLV. The Path Check message is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Path Check TBD | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH STATUS TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Path Check: The type of the Path Check message is to be assigned by IANA. Message Length: Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters. Message ID: 32-bit value used to identify this message. P2MP FEC TLV: Liu Expires August 30, 2006 [Page 7] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 Specifies the P2MP FEC component. It is inherited from [6] and indicates the P2MP LSP that the Path Check message is used to verify. PATH STATUS TLV: Specifies whether a LSP from root LSR to a leaf LSR is the shortest LSP. It is proposed in this document, and encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| PATH STATUS (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PS value | +-+-+-+-+-+-+-+-+ PATH STATUS: The type of the PATH STATUS TLV is to be assigned by IANA. Length: Specifies the length of the Value field in octets. PS value: Specifies whether a LSP from root LSR to a leaf LSR is the shortest LSP. If the PS value is 0, the LSP is the shortest LSP. If the PS value is 1, the LSP is a non-shortest LSP. 4.1.2. Path Modify message A Path Modify message is used to rebuild a non-shortest P2MP LSP into the shortest P2MP LSP. The Path Modify message is created by every leaf LSR which has received a Path Check message with PS value being 1, and sent to the root LSR along the unicast shortest path from the leaf LSR to the root LSR. Every Transit LSR will have some operations after receiving a Path Modify message. The Path Modify message mainly consists of a P2MP FEC TLV and a PATH MODIDY STATUS TLV. The Path Modify message is encoded as follows: Liu Expires August 30, 2006 [Page 8] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| Path Modify TBD | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P2MP FEC TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PATH MODIFY STATUS TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Path Modify: The type of the Path Modify message is to be assigned by IANA. Message Length: Specifies the cumulative length in octets of the Message ID, Mandatory Parameters, and Optional Parameters. Message ID: 32-bit value used to identify this message. P2MP FEC TLV: Specifies the P2MP FEC component. It is inherited from [6] and indicates the P2MP LSP that the Path Modify message is used to rebuild. PATH MODIFY STATUS TLV: Specifies whether a LSP from a leaf LSR to the root LSR has been rebuilt into the shortest LSP. It is proposed in this document, and encoded as follows: Liu Expires August 30, 2006 [Page 9] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| PATH MODIFY STATUS (TBD) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PMS value | +-+-+-+-+-+-+-+-+ PATH MODIFY STATUS: The type of the PATH MODIFY STATUS TLV is to be assigned by IANA. Length: Specifies the length of the Value field in octets. PMS value: Specifies whether a LSP from a leaf LSR to the root LSR has been rebuilt into the shortest LSP. If the PMS value is 0, the LSP has been the shortest LSP. If the PMS value is 1, the LSP is a non- shortest LSP yet. 4.1.3. Path_Modify_Flag The Path_Modify_Flag is added into the structure of multicast forwarding state for a P2MP LSP. It is used to indicate whether a LSR in which the multicast forwarding state resides has received a Path Modify message sent by downstream LSR in the P2MP LSP. If the Path_Modify_Flag is 1, the LSR has received a Path Modify message. If the Path_Modify_Flag is 0, the LSR has not received a Path Modify message yet. The Path_Modify_Flag is set to 0 when a multicast forwarding state is created. 4.2. The operations of Path Check message From every outgoing interface of the multicast forwarding state for a P2MP LSP, the root LSR sends a Path Check message to its downstream LSR. The Path Check message is forwarded towards all the leaf LSRs along the P2MP LSP to verify whether all the LSPs from root LSR to every leaf LSR are the shortest LSPs. Liu Expires August 30, 2006 [Page 10] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 4.2.1. Root LSR operation When a P2MP LSP is built completely, the root LSR will create a timer for the P2MP LSP. If the timer expires, the root LSR will reset the timer and send a Path Check message from every outgoing interface of the multicast forwarding state to its downstream LSR in the P2MP LSP. At the same time, the PS value of PATH STATUS TLV in the Path Check message is set to 0. 4.2.2. Transit LSR operation After receiving a Path Check massage from its upstream in the P2MP LSP, a transit LSR checks the PS value in PATH STATUS TLV. When the PS value is 1, the transit LSR directly sends the Path Check message from every outgoing interface of the multicast forwarding state to its downstream LSR in the P2MP LSP, and sets Path_Modify_Flag in the multicast forwarding state to 0. When the PS value is 0, according unicast routing information, the transit LSR verifies whether the outgoing interface of next hop to the root LSR is the incoming interface of the multicast forwarding state for the P2MP LSP. If the outgoing interface of next hop to the root LSR is the incoming interface of the multicast forwarding state, the transit LSR does not change the PS value. If the outgoing interface of next hop to the root LSR is not the incoming interface of the multicast forwarding state, the transit LSR sets the PS value to 1. At last, the transit LSR sends the Path Check message from every outgoing interface of the multicast forwarding state to its downstream LSR in the P2MP LSP, and sets Path_Modify_Flag in the multicast forwarding state to 0. 4.2.3. Leaf LSR operation After receiving a Path Check massage from its upstream in the P2MP LSP, a leaf LSR checks the PS value in PATH STATUS TLV. When the PS value is 1, the leaf LSR sets Path_Modify_Flag in the multicast forwarding state to 0. When the PS value is 0, according unicast routing information, the leaf LSR verifies whether the outgoing interface of next hop to the root LSR is the incoming interface of the multicast forwarding state for the P2MP LSP. If the outgoing interface of next hop to the root LSR is the incoming interface of the multicast forwarding state, the leaf LSR does not change the PS value. If the outgoing interface of next hop to the root LSR is not the incoming interface of the Liu Expires August 30, 2006 [Page 11] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 multicast forwarding state, the leaf LSR sets the PS value to 1. In the end, the leaf LSR sets Path_Modify_Flag in the multicast forwarding state to 0. After foregoing operations, every leaf LSR checks the PS value in Path Check message. If PS value is 0, the LSP from the leaf LSR to the root LSR is the shortest path, the whole process is complete. If PS value is 1, the LSP for the leaf LSR to the root LSR is not the shortest path, and it must be rebuilt. 4.3. The operations of Path Modify message When the PS value in the received Path Check message is 1, a leaf LSR will send a Path Modify message to its upstream LSR along the unicast shortest path from itself to the root LSR. Then the Path Modify message is forwarded towards the root LSR along the unicast shortest path from the leaf LSR to the root LSR to rebuild the LSP from the leaf LSR to the root LSR into the shortest LSP. 4.3.1. Leaf LSR operation When the PS value in the Path Check message received is 1, according unicast routing information, a leaf LSR will verify whether the outgoing interface of next hop to the root LSR is the incoming interface of the multicast forwarding state for the P2MP LSP. If the outgoing interface of next hop to the root LSR is the incoming interface of the multicast forwarding state, the leaf LSR sends a Path Modify message, in which the PMS value of PATH MODIFY STATUS TLV is 0, to its upstream LSR from the incoming interface of the multicast forwarding state. Otherwise, the leaf LSR assigns a label and adds the outgoing interface of next hop towards the root LSR into incoming interface list of the multicast forwarding state, then the leaf LSR sends a P2MP Label Map message from the outgoing interface of next hop toward the root LSR to its upstream LSR, finally the leaf LSR sends a Path Modify message, in which the PMS value of PATH MODIFY STATUS TLV is set to 0 or 1 according the result of the Label allocation operation, to its upstream LSR along the shortest path to the root LSR. In the end, the leaf LSR sets the Path_Modify_Flag of multicast forwarding state to 1. Liu Expires August 30, 2006 [Page 12] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 4.3.2. Transit LSR operation After receiving a Path Modify message, the transit LSR checks the Path_Modify_Flag of multicast forwarding state. If the value of Path_Modify_Flag is 1, it means the transit LSR has received a Path Modify message and made some operations to rebuild the LSP from itself to the root LSR into the shortest LSP previously. If the PMS value in the received Path Modify message is 0, the whole process is finished, if the PMS value in the received Path Modify message is 1, the transit LSR only sends the received Path Modify message to its upstream LSR from the outgoing interface of next hop to the root LSR. If the value of Path_Modify_Flag is 0, according unicast routing information, the transit LSR will verify whether the outgoing interface of next hop to the root LSR is the incoming interface of the multicast forwarding state for the P2MP LSP. If the outgoing interface of next hop to the root LSR is the incoming interface of the multicast forwarding state, the transit LSR sends the received Path Modify message, in which the PMS value of PATH MODIFY STATUS TLV do not update, to its upstream LSR from the incoming interface of the multicast forwarding state. If the outgoing interface of next hop to the root LSR is not the incoming interface of the multicast forwarding state, the transit LSR assigns a label and adds the outgoing interface of next hop toward the root LSR into incoming interface list of the multicast forwarding state, then the transit LSR sends a P2MP Label Map message from the outgoing interface of next hop toward the root LSR to its upstream LSR. Finally the transit LSR sends the received Path Modify message, in which the PMS value of PATH MODIFY STATUS TLV is updated to 1 or not be updated according the result of the Label allocation operation, to its upstream LSR along the shortest path to the root LSR. In the end, the transit LSR sets the Path_Modify_Flag of multicast forwarding state to 1. 4.3.3. Root LSR operation After receiving a Path Modify message, the root LSR checks the PMS value in the Path Modify message received, if the PMS value is 0, it shows the P2MP LSP has been rebuilt to the shortest LSP. If the PMS value is 1, it shows there were some failures during the rebuilding process. The root LSR will send a Path Check message to its Liu Expires August 30, 2006 [Page 13] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 downstream LSRs along the P2MP LSP until the timer of the P2MP LSP is expired. 4.4. An example of rebuilding one P2MP LSP This section gives an example of rebuilding a non-shortest P2MP LSP into the shortest P2MP LSP. ---------[R4]---receiver1 / / source--[R1]------[R2]------[R3]-----[R5]---receiver2 the metric of R1->R2: 5 ; the metric of R2->R3: 5 the metric of R2->R4: 11 ; the metric of R3->R4: 5 the metric of R3->R5: 5 figure 2: an example of rebuilding a non-shortest P2MP LSP into the shortest P2MP LSP In figure 2, there are five LSRs: R1, R2, R3, R4 and R5. R1 is root LSR, R4 and R5 are leaf LSRs. Along the best path from leaf LSRs to the root LSR, two LSPs have been built i.e. R1->R2->R3->R4 and R1- >R2->R3->R5. When the metric of R2->R4 is changed to 6, the P2MP LSP will become a non-shortest P2MP LSP. LSRs including R1, R2, R3, R4 and R5 do not update their multicast forwarding state with changes of unicast routing information. When the timer for the P2MP LSP is expired, R1 sends a Path Check message, in which the PS value of PATH STATUS TLV is set to 0, to R2. After receiving the Path Check message from R1, R2 does not update the PS value in the Path Check message because the outgoing interface of next hop to R1 is the incoming interface of the multicast forwarding state for the P2MP LSP, then it sends the Path Check message to R3. Same as R2, R3 does not update the PS value in the Path Check message received either and sends the Path Check message to R4 and R5. On receiving the Path Check message, R5 does not update the PS value yet, but R4 set the PS value to 1 because the outgoing interface of next hop to R1 is not the incoming interface of the multicast forwarding state for the P2MP LSP. When R2, R3, R4, and R5 receive the Path Check message, they all set the Path_Modify_Flag in the multicast forwarding state for the P2MP LSP to 0. Liu Expires August 30, 2006 [Page 14] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 R5 checks the PS value of the Path Check message. The PS value is 0 shows R1->R2->R3->R5 is the shortest LSP, so R5 does not send a Path Modify message to R3 any more. R4 checks the PS value of the Path Check message. The PS value is 1 shows R1->R2->R3->R4 is a non-shortest LSP. R4 finds that the outgoing interface of next hop to R1 is not the incoming interface of the multicast forwarding state for the P2MP LSP, so it assigns a label and sends a P2MP Label Map message from the outgoing interface of next hop towards R1 to R2. Then R4 adds the outgoing interface of next hop toward R1 into the incoming interface list, at last, R4 send a Path Modify message to R2 and set the Path_Modify_Flag in the multicast forwarding state to 1. After R2 receives the Path Modify message from R4, it finds the Path_Modify_Flag in the multicast forwarding state is 0 and the outgoing interface of next hop to R1 is the incoming interface of the multicast forwarding state, so R2 only sends the Path Modify message to R1 and sets the Path_Modify_Flag in the multicast forwarding state to 1. When R1 receives the Path Modify message with a PMS value being 0, it shows that the P2MP LSP has become the shortest P2MP LSP, the whole process is finished. In the end, there are three LSPs: R1->R2->R3->R5, R1->R2->R3->R4 and R1->R2->R4. R1->R2->R3->R5 and R1->R2->R4 are shortest LSPs, R1->R2- >R3->R4 is a non-shortest and unwanted LSP. 5. Installing multicast forwarding state to LFIB After the processes of rebuilding a non-shortest P2MP LSP into the shortest P2MP LSP mentioned above, there still are some non-shortest and unwanted LSPs, such as R1->R2->R3->R4 in figure 2, and some LSRs with two incoming interfaces in the multicast forwarding state, such as R4 in figure 2, in the P2MP LSP. The LSRs with two incoming interfaces in the multicast forwarding state will receive two same multicast packets from the two incoming interfaces, the situation is data duplication which is detrimental for certain multicast applications. To avoid data duplication as much as possible, this document introduces the modification to the process of installing multicast forwarding states to LFIB. When LDP creates a multicast forwarding state for a P2MP LSP, it does not install the multicast forwarding state into LFIB as a multicast forwarding item until it receives an unknown multicast packet. After a LSR receives one multicast packet for a multicast group, it lookups a multicast forwarding item for the multicast group in LFIB, if the multicast forwarding item is found, the multicast packet will be Liu Expires August 30, 2006 [Page 15] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 forwarded according the multicast forwarding item; if the multicast forwarding item is not found, the multicast packet will be sent to the LDP module as an unknown multicast packet. When the LDP module receives an unknown multicast packet, it will search the multicast forwarding state for the unknown multicast packet. If the multicast forwarding state is not found, the LDP module will create a multicast forwarding state and install the multicast forwarding state into LFIB, in the multicast forwarding state, there is no outgoing interface and only one incoming interface that is exactly the interface where the unknown multicast packet come. On the other hand, if the multicast forwarding state is found, the LDP module will check the number of incoming interface in the multicast forwarding state. When the number is 1, the LDP module installs the multicast forwarding state into LFIB at once. When the number is 2, the LDP module deletes the multicast forwarding item in LFIB for the multicast forwarding state firstly, then the LDP module deletes the incoming interface, which is not the outgoing interface of next hop to the root LSR, in the multicast forwarding state and sends a P2MP label withdraw message from the incoming interface being deleted to the LDP peer LSR, finally the LDP module installs the multicast forwarding state into LFIB. 6. Special operations during local repairing and rebuilding P2MP LSP A problem exists during local repairing in section 3 and rebuilding P2MP LSP in section 4. When a LSR receives a P2MP label map message and modifies the multicast forwarding state for the P2MP LSP, there may be an interface which not only is the incoming interface but also is the outgoing interface in the multicast forwarding state. This document introduces some special operations to cope with the problem. When a LSR receives a P2MP label map message for the P2MP LSP, it checks whether the incoming interface in the multicast forwarding state is the interface where the P2MP label map message comes. If the incoming interface in the multicast forwarding state is the interface where the P2MP label map message comes, the LSR will add the interface and the label to the outgoing interface list in the multicast forwarding state. But the LSR does not install the interface into the outgoing interface list in LFIB at the time. When the LDP module receives an unknown multicast packet for the multicast forwarding state, it takes the same operations as mentioned in section 5. Liu Expires August 30, 2006 [Page 16] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 7. Security Considerations The security considerations for the base LDP specification described in [2] is applied here as well. 8. IANA Considerations This document creates two new LDP message types: the Path Check message and the Path Modify message types that is to be managed by IANA. Also, this document requires allocation of two new LDP TLV types: the PATH STATUS and the PATH MODIFY STATUS types. 9. Acknowledgments The authors would like to thank Hui LIU for her review and contribution. Liu Expires August 30, 2006 [Page 17] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] C Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B.Thomas, "LDP Specification", RFC 3036, January 2001. [3] Roux, J., "Requirements for point-to-multipoint extensions tothe Label Distribution Protocol",draft-leroux-mpls-mp-ldp- reqs-01 (work in progress), July 2005. [4] T. Morin, Ed., "Requirements for Multicast in L3 Provider- Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts, work in progress. [5] Y. Kamite et al. " Requirements for Multicast Support in Virtual Private LAN Services", draft-kamite-l2vpn-vpls- mcast-reqts, work in progress [6] Minei, I., et al., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths",draft-minei-wijnands-mpls-ldp-p2mp, work in progress. 10.2. Informative References [7] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf-mpls-rsvp-te-p2mp-02 (work in progress), July 2005. [8] Aggarwal, R., "MPLS Upstream Label Assignment and Context Specific Label Space", draft-raggarwa-mpls-upstream-label-00 (work in progress), April 2005. Liu Expires August 30, 2006 [Page 18] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 Author's Addresses Shuying Liu Huawei Technologies Email: lshuying@huawei.com Gang Cheng Huawei Technologies Email: chenggang@huawei.com Lianshu Zheng Huawei Technologies Email: verozheng@huawei.com Liu Expires August 30, 2006 [Page 19] Internet-Draft Reroute Extensions to LDP for P2MP LSP February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Liu Expires August 30, 2006 [Page 20]