< draft-ietf-mpls-ldp-upstream-09.txt   draft-ietf-mpls-ldp-upstream-10.txt >
Network Working Group R. Aggarwal Network Working Group R. Aggarwal
Internet Draft Juniper Networks Internet Draft Juniper Networks
Category: Standards Track Category: Standards Track
Expiration Date: May 2011 Expiration Date: August 2011
J. L. Le Roux J. L. Le Roux
France Telecom France Telecom
November 16, 2010 February 02, 2011
MPLS Upstream Label Assignment for LDP MPLS Upstream Label Assignment for LDP
draft-ietf-mpls-ldp-upstream-09.txt draft-ietf-mpls-ldp-upstream-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright and License Notice Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 14 skipping to change at page 4, line 14
upstream-assigned labels. upstream-assigned labels.
The usage of MPLS upstream label assignment using LDP for avoiding The usage of MPLS upstream label assignment using LDP for avoiding
branch LSR traffic replication on a LAN for LDP point-to-multipoint branch LSR traffic replication on a LAN for LDP point-to-multipoint
(P2MP) Label Switched Paths (LSPs) [MLDP] is also described. (P2MP) Label Switched Paths (LSPs) [MLDP] is also described.
3. LDP Upstream Label Assignment Capability 3. LDP Upstream Label Assignment Capability
According to [RFC5331], upstream-assigned label bindings MUST NOT be According to [RFC5331], upstream-assigned label bindings MUST NOT be
used unless it is known that a downstream LSR supports them. This used unless it is known that a downstream LSR supports them. This
implies that there MUST be a mechanism to enable a LSR to advertise implies that there MUST be a mechanism to enable an LSR to advertise
to its LDP neighbor LSR(s) its support of upstream-assigned labels. to its LDP neighbor LSR(s) its support of upstream-assigned labels.
A new Capability Parameter, the LDP Upstream Label Assignment A new Capability Parameter, the LDP Upstream Label Assignment
Capability, is introduced to allow an LDP peer to exchange with its Capability, is introduced to allow an LDP peer to exchange with its
peers, its support of upstream label assignment. This parameter peers, its support of upstream label assignment. This parameter
follows the format and procedures for exchanging Capability follows the format and procedures for exchanging Capability
Parameters defined in [RFC5561]. Parameters defined in [RFC5561].
Following is the format of the LDP Upstream Label Assignment Following is the format of the LDP Upstream Label Assignment
Capability Parameter: Capability Parameter:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) | |1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | |1| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
If a LSR includes the Upstream Label Assignment Capability in LDP If an LSR includes the Upstream Label Assignment Capability in LDP
Initialization Messages it implies that the LSR is capable of both Initialization Messages it implies that the LSR is capable of both
distributing upstream-assigned label bindings and receiving upstream- distributing upstream-assigned label bindings and receiving upstream-
assigned label bindings. The reserved bits MUST be set to zero on assigned label bindings. The reserved bits MUST be set to zero on
transmission and ignored on receipt. The Upstream Label Assignment transmission and ignored on receipt. The Upstream Label Assignment
Capability Parameter MUST be carried only LDP initialization messages Capability Parameter MUST be carried only in LDP initialization
and MUST be ignored if received in LDP Capability messages. messages and MUST be ignored if received in LDP Capability messages.
4. Distributing Upstream-Assigned Labels in LDP 4. Distributing Upstream-Assigned Labels in LDP
An optional LDP TLV, Upstream-Assigned Label Request TLV, is An optional LDP TLV, Upstream-Assigned Label Request TLV, is
introduced. To request an upstream-assigned label a LDP peer MUST introduced. To request an upstream-assigned label an LDP peer MUST
include this TLV in a Label Request message. include this TLV in a Label Request message.
0 1 2 3 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 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| Upstream Ass Lbl Req (TBD)| Length | |0|0| Upstream Ass Lbl Req (TBD)| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 11 skipping to change at page 6, line 11
Request TLV to a neighboring LSR if the neighboring LSR had not Request TLV to a neighboring LSR if the neighboring LSR had not
previously advertised the Upstream Label Assignment Capability in its previously advertised the Upstream Label Assignment Capability in its
LDP Initialization messages. LDP Initialization messages.
As described in [RFC5331] the distribution of upstream-assigned As described in [RFC5331] the distribution of upstream-assigned
labels is similar to either ordered LSP control or independent LSP labels is similar to either ordered LSP control or independent LSP
control of the downstream assigned labels. control of the downstream assigned labels.
When the label distributed in a Label Mapping message is an upstream- When the label distributed in a Label Mapping message is an upstream-
assigned label, the Upstream Assigned Label TLV MUST be included in assigned label, the Upstream Assigned Label TLV MUST be included in
the Label Mapping message. When a LSR receives a Label Mapping the Label Mapping message. When an LSR receives a Label Mapping
message with an Upstream Assigned Label TLV and it does not recognize message with an Upstream Assigned Label TLV and it does not recognize
the TLV, it MUST generate a Notification message with a status code the TLV, it MUST generate a Notification message with a status code
of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is
unable to process the upstream label, it MUST generate a Notification unable to process the upstream label, it MUST generate a Notification
message with a status code of "No Label Resources". If the Label message with a status code of "No Label Resources". If the Label
Mapping message was generated in response to a Label Request message, Mapping message was generated in response to a Label Request message,
the Label Request message MUST contain an Upstream Assigned Label the Label Request message MUST contain an Upstream Assigned Label
Request TLV. A LSR that generates an upstream assigned label request Request TLV. A LSR that generates an upstream assigned label request
to a neighbor LSR, for a given FEC, MUST NOT send a downstream label to a neighbor LSR, for a given FEC, MUST NOT send a downstream label
mapping to the neighbor LSR for that FEC unless it withdraws the mapping to the neighbor LSR for that FEC unless it withdraws the
upstream-assigned label binding. Similarly if a LSR generates a upstream-assigned label binding. Similarly if an LSR generates a
downstream assigned label request to a neighbor LSR, for a given FEC, downstream assigned label request to a neighbor LSR, for a given FEC,
it MUST NOT send an upstream label mapping to that LSR for that FEC, it MUST NOT send an upstream label mapping to that LSR for that FEC,
unless it aborts the downstream assigned label request. unless it aborts the downstream assigned label request.
The Upstream Assigned Label TLV may be optionally included in Label The Upstream Assigned Label TLV may be optionally included in Label
Withdraw and Label Release messages that withdraw/release a Withdraw and Label Release messages that withdraw/release a
particular upstream assigned label binding. particular upstream assigned label binding.
5. LDP Tunnel Identifier Exchange 5. LDP Tunnel Identifier Exchange
As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS As described in [RFC5331] an upstream LSR Ru MAY transmit an MPLS
packet, the top label of which (L) is upstream-assigned, to a packet, the top label of which (L) is upstream-assigned, to a
downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In
this case the fact that L is upstream-assigned is determined by Rd by this case the fact that L is upstream-assigned is determined by Rd by
the tunnel on which the packet is received. There must be a mechanism the tunnel on which the packet is received. There must be a mechanism
for Ru to inform Rd that a particular tunnel from Ru to Rd will be for Ru to inform Rd that a particular tunnel from Ru to Rd will be
used by Ru for transmitting MPLS packets with upstream-assigned MPLS used by Ru for transmitting MPLS packets with upstream-assigned MPLS
labels. labels.
When LDP is used for upstream label assignment, the Interface ID TLV When LDP is used for upstream label assignment, the Interface ID TLV
[RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an
IP or MPLS tunnel to transmit MPLS packets with upstream assigned IP or MPLS tunnel to transmit MPLS packets with upstream assigned
labels to Rd, Ru MUST include the Interface ID TLV in the Label labels to Rd, Ru MUST include the Interface ID TLV in the Label
Mapping messages along with the Upstream Assigned Label TLV. The Mapping messages along with the Upstream Assigned Label TLV. The
IPv4/v6 Next/Previous Hop Address and the Logical Interface ID fields IPv4/v6 Next/Previous Hop Address and the Logical Interface ID fields
in the Interface ID TLV SHOULD be set to 0 by the sender and ignored in the Interface ID TLV SHOULD be set to 0 by the sender and ignored
by the receiver. by the receiver. The Length field indicates the total length of the
TLV, i.e., 4 + the length of the value field in octets. A value
field whose length is not a multiple of four MUST be zero-padded so
that the TLV is four- octet aligned.
Hence the IPv4 Interface ID TLV has the following format: Hence the IPv4 Interface ID TLV has the following format:
0 1 2 3 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 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| Type (0x082d) | Length | |0|0| Type (0x082d) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Next/Previous Hop Address (0) | | IPv4 Next/Previous Hop Address (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 33 skipping to change at page 7, line 36
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address (0) | | IPv6 Next/Previous Hop Address (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID (0) | | Logical Interface ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs | | Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As shown in the above figures the Interface ID TLV carries sub-TLVs. As shown in the above figures the Interface ID TLV carries sub-TLVs.
Four new Interface ID sub-TLVs are introduced to support RSVP-TE P2MP Four new Interface ID sub-TLVs are introduced to support RSVP-TE P2MP
LSPs, LDP P2MP LSPs, IP Multicast Tunnels and context labels. The TLV LSPs, LDP P2MP LSPs, IP Multicast Tunnels and context labels. The
value in the sub-TLV acts as the tunnel identifier. sub-TLV value in the sub-TLV acts as the tunnel identifier.
Following are the sub-TLVs that are introduced: Following are the sub-TLVs that are introduced:
1. RSVP-TE P2MP LSP TLV. Type = 28 (To be assigned by IANA). Value of 1. RSVP-TE P2MP LSP TLV. Type = 28 (To be assigned by IANA). Value of
the TLV is as carried in the RSVP-TE P2MP LSP SESSION Object the TLV is the RSVP-TE P2MP LSP SESSION Object [RFC4875].
[RFC4875].
Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv4 Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv4
Interface ID TLV: Interface ID TLV:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 28 | 16 | | Type (0x1c) | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID | | P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID | | MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv6 Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv6
Interface ID TLV: Interface ID TLV:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 28 | 28 | | Type (0x1c) | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID | | P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID | | MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
| | | |
| ....... | | ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 49 skipping to change at page 10, line 7
an upstream assigned label, assigned by Ru. The Source Address MUST an upstream assigned label, assigned by Ru. The Source Address MUST
be set to an IPv4 address when the MPLS Context Label TLV is carried be set to an IPv4 address when the MPLS Context Label TLV is carried
in the IPv4 Interface ID TLV. The Source Address MUST be set to an in the IPv4 Interface ID TLV. The Source Address MUST be set to an
IPv6 address when the MPLS Context Label TLV is carried in the IPv6 IPv6 address when the MPLS Context Label TLV is carried in the IPv6
Interface ID TLV. This allows Ru to tunnel an "inner" LDP P2MP LSP, Interface ID TLV. This allows Ru to tunnel an "inner" LDP P2MP LSP,
the label of which is upstream assigned, over an "outer" one-hop MPLS the label of which is upstream assigned, over an "outer" one-hop MPLS
LSP, where the outer one-hop LSP has the following property: LSP, where the outer one-hop LSP has the following property:
+ The label pushed by Ru for the outer MPLS LSP is an upstream + The label pushed by Ru for the outer MPLS LSP is an upstream
assigned context label, assigned by Ru. When <Rd1...Rdn> perform assigned context label, assigned by Ru. When <Rd1...Rdn> perform
a MPLS label lookup on this label a combination of this label and an MPLS label lookup on this label a combination of this label
the incoming interface MUST be sufficient for <Rd1...Rdn> to and the incoming interface MUST be sufficient for <Rd1...Rdn> to
uniquely determine Ru's context specific label space to lookup uniquely determine Ru's context specific label space to lookup
the next label on the stack in. <Rd1...Rdn> MUST receive the data the next label on the stack in. <Rd1...Rdn> MUST receive the data
sent by Ru with the context specific label assigned by Ru being sent by Ru with the context specific label assigned by Ru being
the top label on the label stack. the top label on the label stack.
Currently the usage of the context label TLV is limited only to LDP Currently the usage of the context label TLV is limited only to LDP
P2MP LSPs on a LAN as specified in the next section. The context P2MP LSPs on a LAN as specified in the next section. The context
label TLV MUST NOT be used for any other purposes. label TLV MUST NOT be used for any other purposes.
Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP
skipping to change at page 10, line 28 skipping to change at page 10, line 33
does not provide this information to Ru. In this scenario the does not provide this information to Ru. In this scenario the
procedures by which Ru could acquire this information are outside the procedures by which Ru could acquire this information are outside the
scope of this document. scope of this document.
6. LDP Point-to-Multipoint LSPs on a LAN 6. LDP Point-to-Multipoint LSPs on a LAN
This section describes one application of upstream label assignment This section describes one application of upstream label assignment
using LDP. Further applications are to be described in separate using LDP. Further applications are to be described in separate
documents. documents.
[MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the [MLDP] describes how to setup P2MP LSPs using LDP. On a LAN the
solution relies on "ingress replication". A LSR on a LAN, that is a solution relies on "ingress replication". A LSR on a LAN, that is a
branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet
that it receives on the P2MP LSP to each of the downstream LSRs on that it receives on the P2MP LSP to each of the downstream LSRs on
the LAN (say <Rd1...Rdn> that are adjacent to it in the P2MP LSP. the LAN (say <Rd1...Rdn> that are adjacent to it in the P2MP LSP.
It is desirable for Ru to send a single copy of the packet for the It is desirable for Ru to send a single copy of the packet for the
LDP P2MP LSP on the LAN, when there are multiple downstream routers LDP P2MP LSP on the LAN, when there are multiple downstream routers
on the LAN that are adjacent to Ru in that LDP P2MP LSP. This on the LAN that are adjacent to Ru in that LDP P2MP LSP. This
requires that each of <Rd1...Rdn> must be able to associate the label requires that each of <Rd1...Rdn> must be able to associate the label
L, used by Ru to transmit packets for the P2MP LSP on the LAN, with L, used by Ru to transmit packets for the P2MP LSP on the LAN, with
that P2MP LSP. It is possible to achieve this using LDP upstream- that P2MP LSP. It is possible to achieve this using LDP upstream-
assigned labels with the following procedures. assigned labels with the following procedures.
Consider a LSR Rd that receives the LDP P2MP FEC [MLDP] from its Consider an LSR Rd that receives the LDP P2MP FEC [MLDP] from its
downstream LDP peer. Further the upstream interface to reach LSR Ru downstream LDP peer. Further the upstream interface to reach LSR Ru
which is the next-hop to the P2MP LSP root address, Pr, in the LDP which is the next-hop to the P2MP LSP root address, Pr, in the LDP
P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream- P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream-
assigned labels. In this case Rd instead of sending a Label Mapping assigned labels. In this case Rd instead of sending a Label Mapping
message as described in [MLDP] sends a Label Request message to Ru. message as described in [MLDP] sends a Label Request message to Ru.
This Label Request message MUST contain an Upstream Assigned Label This Label Request message MUST contain an Upstream Assigned Label
Request TLV. Request TLV.
Ru on receiving this message sends back a Label Mapping message to Rd On receiving this message, Ru sends back a Label Mapping message to
with an upstream-assigned label. This message also contains an Rd with an upstream-assigned label. This message also contains an
Interface ID TLV with a MPLS Context Label sub-TLV, as described in Interface ID TLV with a MPLS Context Label sub-TLV, as described in
the previous section, with the value of the MPLS label set to a value the previous section, with the value of the MPLS label set to a value
assigned by Ru on inteface Li as specified in [RFC5331]. Processing assigned by Ru on inteface Li as specified in [RFC5331]. Processing
of the Label Request and Label Mapping messages for LDP upstream- of the Label Request and Label Mapping messages for LDP upstream-
assigned labels is as described in section 4.2. If Ru receives a assigned labels is as described in section 4.1. If Ru receives a
Label Request for an upstream assigned label for the same P2MP FEC Label Request for an upstream assigned label for the same P2MP FEC
from multiple downstream LSRs on the LAN, <Rd1...Rdn>, it MUST send from multiple downstream LSRs on the LAN, <Rd1...Rdn>, it MUST send
the same upstream-assigned label to each of <Rd1...Rdn>. the same upstream-assigned label to each of <Rd1...Rdn>.
Ru transmits the MPLS packet using the procedures defined in Ru transmits the MPLS packet using the procedures defined in
[RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains [RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains
as the top label the context label assigned by Ru on the LAN as the top label the context label assigned by Ru on the LAN
interface, Li. The bottom label is the upstream label assigned by Ru interface, Li. The bottom label is the upstream label assigned by Ru
to the LDP P2MP LSP. The top label is looked up in the context of the to the LDP P2MP LSP. The top label is looked up in the context of the
LAN interface, Li, [RFC5331] by a downstream LSR on the LAN. This LAN interface, Li, [RFC5331] by a downstream LSR on the LAN. This
 End of changes. 21 change blocks. 
26 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/