Internet DRAFT - draft-liu-mpls-ldp-p2mp-reroute
draft-liu-mpls-ldp-p2mp-reroute
Network Working Group Shuying Liu
Internet Draft Gang Cheng
Expires: February 25, 2007 Lianshu Zheng
Huawei Technologies
August 25, 2006
Reroute Extensions to LDP for P2MP LSP
draft-liu-mpls-ldp-p2mp-reroute-01.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 February 25, 2007.
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 February 25, 2007 [Page 1]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 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
.
Table of Contents
1. Terminology......................................................3
2. Introduction.....................................................3
3. Local repair techniques for a P2MP LSP under network failure.....4
3.1. Technique to find the downstream adjoining LSR of a failed
link or a failed LSR.............................................5
3.2. Rebuilding the LSP from the downstream LSR to the root LSR..5
3.2.1. Processes for one P2MP LSP.............................5
3.2.2. Processes for many P2MP LSPs...........................5
3.3. An example of local repair..................................6
4. Rebuilding a non-shortest P2MP LSP into the shortest P2MP LSP....7
4.1. LDP Extensions..............................................7
4.1.1. Path Check message.....................................7
4.1.2. Path Modify message....................................9
4.1.3. Path_Modify_Flag......................................11
4.2. The operations of Path Check message.......................11
4.2.1. Root LSR operation..........................................11
4.2.2. Transit LSR operation.......................................11
4.2.3. Leaf LSR operation..........................................12
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..........................................14
4.4. An example of rebuilding one P2MP LSP......................14
5. Installing multicast forwarding state to LFIB...................15
6. 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.................................................18
Intellectual Property Statement....................................19
Disclaimer of Validity.............................................19
Copyright Statement................................................19
Liu Expires February 25, 2007 [Page 2]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
Acknowledgment.....................................................19
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
rerouting mechanism for P2MP LSP and MP2MP LSP when unicast routing
Liu Expires February 25, 2007 [Page 3]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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 under 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 February 25, 2007 [Page 4]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 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. Rebuilding the LSP from the downstream LSR to the root LSR
3.2.1. Processes for one P2MP LSP
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.2.2. Processes for many P2MP LSPs
When a link or a LSR fails, many P2MP LSPs may be affected. For some
P2MP LSPs, there may be a common downstream adjoining LSR and a
Liu Expires February 25, 2007 [Page 5]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
common new upstream LSR, the downstream adjoining LSR could assign
labels for those P2MP LSPs and compress these labels into a P2MP
label Map message, then it sends the P2MP Label Map message to the
new upstream LSR along the best path. The LSR which receives the P2MP
Label Map message later could take the same operations as above if
many P2MP LSPs have a common upstream LSR. This process will be
repeated step by step until every P2MP LSP is rebuilt to its root LSR.
When the downstream adjoining LSR in a P2MP LSP can not find the next
hop to the root LSR, it will take the same operations as section
3.2.1.
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.
[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
Liu Expires February 25, 2007 [Page 6]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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.
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 |
Liu Expires February 25, 2007 [Page 7]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
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:
Liu Expires February 25, 2007 [Page 8]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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:
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:
Liu Expires February 25, 2007 [Page 9]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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:
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.
Liu Expires February 25, 2007 [Page 10]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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.
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
Liu Expires February 25, 2007 [Page 11]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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
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
Liu Expires February 25, 2007 [Page 12]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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.
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
Liu Expires February 25, 2007 [Page 13]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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
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.
Liu Expires February 25, 2007 [Page 14]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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.
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
Liu Expires February 25, 2007 [Page 15]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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
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. 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
Liu Expires February 25, 2007 [Page 16]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 2006
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.
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 their review and
contribution.
Liu Expires February 25, 2007 [Page 17]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 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 to
the Label Distribution Protocol",draft-ietf-mpls-mp-ldp-reqs-
01, July 2006.
[4] T. Morin, Ed., "Requirements for Multicast in L3 Provider-
Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts, work in
progress.
[5] Minei, I., et al., "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths",draft-ietf-mpls-ldp-p2mp-01, work in progress.
10.2. Informative References
[6] Aggarwal, R., "Extensions to RSVP-TE for Point to Multipoint TE
LSPs", draft-ietf-mpls-rsvp-te-p2mp-06 (work in progress),
July 2005.
[7] Aggarwal, R., "MPLS Upstream Label Assignment and Context
Specific Label Space", draft-ietf-mpls-upstream-label-00
(work in progress), 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 February 25, 2007 [Page 18]
Internet-Draft Reroute Extensions to LDP for P2MP LSP August 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 February 25, 2007 [Page 19]
