draft-ietf-mpls-ldp-upstream-07.txt   draft-ietf-mpls-ldp-upstream-08.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: September 2010 Expiration Date: January 2011
J. L. Le Roux J. L. Le Roux
France Telecom France Telecom
March 2, 2010 July 26, 2010
MPLS Upstream Label Assignment for LDP MPLS Upstream Label Assignment for LDP
draft-ietf-mpls-ldp-upstream-07.txt draft-ietf-mpls-ldp-upstream-08.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 2, line 22 skipping to change at page 2, line 22
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Abstract Abstract
This document describes procedures for distributing upstream-assigned This document describes procedures for distributing upstream-assigned
labels for Label Distribution Protocol (LDP). It also describes how labels for Label Distribution Protocol (LDP). It also describes how
these procedures can be used for avoiding branch LSR traffic these procedures can be used for avoiding branch Label Switching
replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. Router (LSR) traffic replication on a LAN for LDP point-to-multipoint
(P2MP) Label Switched Paths (LSPs).
Table of Contents Table of Contents
1 Specification of requirements ......................... 3 1 Specification of requirements ......................... 3
2 Introduction .......................................... 3 2 Introduction .......................................... 3
3 LDP Upstream Label Assignment Capability .............. 4 3 LDP Upstream Label Assignment Capability .............. 4
4 Distributing Upstream-Assigned Labels in LDP .......... 5 4 Distributing Upstream-Assigned Labels in LDP .......... 5
4.1 Procedures ............................................ 5 4.1 Procedures ............................................ 5
5 LDP Tunnel Identifier Exchange ........................ 6 5 LDP Tunnel Identifier Exchange ........................ 6
6 LDP Point-to-Multipoint LSPs on a LAN ................. 8 6 LDP Point-to-Multipoint LSPs on a LAN ................. 10
7 IANA Considerations ................................... 9 7 IANA Considerations ................................... 12
7.1 LDP TLVs .............................................. 9 7.1 LDP TLVs .............................................. 12
7.2 Interface Type Identifiers ............................ 10 7.2 Interface Type Identifiers ............................ 12
8 Security Considerations ............................... 10 8 Security Considerations ............................... 12
9 Acknowledgements ...................................... 11 9 Acknowledgements ...................................... 13
10 References ............................................ 11 10 References ............................................ 13
10.1 Normative References .................................. 11 10.1 Normative References .................................. 13
10.2 Informative References ................................ 11 10.2 Informative References ................................ 13
11 Author's Address ...................................... 12 11 Author's Address ...................................... 14
1. Specification of requirements 1. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This document describes procedures for distributing upstream-assigned This document describes procedures for distributing upstream-assigned
labels [RFC5331] for Label Distribution Protocol (LDP). These labels [RFC5331] for Label Distribution Protocol (LDP) [RFC5036].
procedures follow the architecture for MPLS Upstream Label Assignment These procedures follow the architecture for MPLS Upstream Label
described in [RFC5331]. Assignment described in [RFC5331].
This document describes extensions to LDP that a LSR can use to This document describes extensions to LDP that a Label Switching
advertise to its neighboring LSRs whether the LSR supports upstream Router (LSR) can use to advertise to its neighboring LSRs whether the
label assignment. LSR supports upstream label assignment.
This document also describes extensions to LDP to distribute This document also describes extensions to LDP to distribute
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 P2MP LSPs [MLDP] is branch LSR traffic replication on a LAN for LDP point-to-multipoint
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 a 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
skipping to change at page 4, line 39 skipping to change at page 4, line 39
|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 a 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 can be exchanged only in LDP initialization Capability Parameter MUST be carried only LDP initialization 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. This TLV MUST be carried in a Label Request message if introduced. To request an upstream-assigned label a LDP peer MUST
an upstream-assigned label is being requested. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An optional LDP TLV, Upstream-Assigned Label TLV is introduced to An optional LDP TLV, Upstream-Assigned Label TLV is introduced to
skipping to change at page 5, line 34 skipping to change at page 5, line 34
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 Label (TBD) | Length | |0|0| Upstream Ass Label (TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is a 20-bit label value as specified in [RFC3032] represented as The Label field is a 20-bit label value as specified in [RFC3032]
a 20-bit number in a 4 octet field. represented as a 20-bit number in a 4 octet field as specified in
section 3.4.2.1 of RFC5036 [RFC5036].
4.1. Procedures 4.1. Procedures
Procedures for Label Mapping, Label Request, Label Abort, Label Procedures for Label Mapping, Label Request, Label Abort, Label
Withdraw and Label Release follow [RFC5036] other than the Withdraw and Label Release follow [RFC5036] other than the
modifications pointed out in this section. modifications pointed out in this section.
A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a
neighboring LSR if the neighboring LSR had not previously advertised neighboring LSR if the neighboring LSR had not previously advertised
the Upstream Label Assignment Capability in its LDP Initialization the Upstream Label Assignment Capability in its LDP Initialization
skipping to change at page 6, line 51 skipping to change at page 6, line 51
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 Interface ID TLV carries sub-TLVs. Four new Interface ID sub-TLVs Hence the IPv4 Interface ID TLV has the following format:
are introduced to support RSVP-TE P2MP LSPs, LDP P2MP LSPs, IP
Multicast Tunnels and context labels. The TLV value in the sub-TLV
acts as the tunnel identifier. Following are the sub-TLVs that are
introduced:
1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is 0 1 2 3
<Extended Tunnel ID, Reserved, Tunnel ID, P2MP ID> as carried in the 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
RSVP-TE P2MP LSP SESSION Object [RFC4875]. The TLV value identifies +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
the RSVP-TE P2MP LSP. It allows Ru to tunnel an "inner" LDP P2MP LSP, |0|0| Type (0x082d) | Length |
the label for which is upstream assigned, over an "outer" RSVP-TE +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
P2MP LSP that has leaves <Rd1...Rdn>. The RSVP-TE P2MP LSP IF_ID TLV | IPv4 Next/Previous Hop Address (0) |
allows Ru to signal to <Rd1...Rdn> the binding of the inner LDP P2MP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LSP to the outer RSVP-TE P2MP LSP. The control plane signaling | Logical Interface ID (0) |
between Ru and <Rd1...Rdn> for the inner P2MP LSP uses targeted LDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
signaling messages | Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC The IPv6 Interface ID TLV has the following format:
as defined in [MLDP]. The TLV value identifies the LDP P2MP LSP. It
allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is
upstream assigned, over an "outer" LDP P2MP LSP that has leaves
<Rd1...Rdn>. The LDP P2MP LSP IF_ID TLV allows Ru to signal to
<Rd1...Rdn> the binding of the inner LDP P2MP LSP to the outer LDP-
P2MP LSP. The control plane signaling between Ru and <Rd1...Rdn> for
the inner P2MP LSP uses targeted LDP signaling messages
3. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 0 1 2 3
a <Source Address, Multicast Group Address> tuple. Source Address is 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
the IP address of the root of the tunnel i.e. Ru, and Multicast Group +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address is the Multicast Group Address used by the tunnel. |0|0| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Next/Previous Hop Address (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4. MPLS Context Label TLV. Type = TBD. In this case the TLV value is As shown in the above figures the Interface ID TLV carries sub-TLVs.
a <Source Address, MPLS Context Label> tuple. The Source Address Four new Interface ID sub-TLVs are introduced to support RSVP-TE P2MP
belongs to Ru and the MPLS Context Label is an upstream assigned LSPs, LDP P2MP LSPs, IP Multicast Tunnels and context labels. The TLV
label, assigned by Ru. This allows Ru to tunnel an "inner" LDP P2MP value in the sub-TLV acts as the tunnel identifier.
LSP, the label of which is upstream assigned, over an "outer" one-hop
MPLS LSP, where the outer one-hop LSP has the following property: Following are the sub-TLVs that are introduced:
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
[RFC4875].
Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv4
Interface ID TLV:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 28 | 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv6
Interface ID TLV:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 28 | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
| |
| ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV identifies the RSVP-TE P2MP LSP. It allows Ru to tunnel an
"inner" LDP P2MP LSP, the label for which is upstream assigned, over
an "outer" RSVP-TE P2MP LSP that has leaves <Rd1...Rdn>. The RSVP-TE
P2MP LSP IF_ID TLV allows Ru to signal to <Rd1...Rdn> the binding of
the inner LDP P2MP LSP to the outer RSVP-TE P2MP LSP. The control
plane signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP
uses targeted LDP signaling messages
2. LDP P2MP LSP TLV. Type = 29 (To be assigned by IANA). Value of the
TLV is the LDP P2MP FEC as defined in [MLDP] and has to be set as per
the procedures in [MLDP]. Here is the format of the LDP P2MP FEC as
defined in [MLDP]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P2MP Type | Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Root Node Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
~ ~
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Address Family MUST be set to IPv4, the Address Length MUST be
set to 4 and the Root Node Address MUST be set to an IPv4 address
when the LDP P2MP LSP TLV is carried in the IPv4 Interface ID TLV.
The Address Family MUST be set to IPv6, the Address Length MUST be
set to 16 and the Root Node Address MUST be set to an IPv6 address
when the LDP P2MP LSP TLV is carried in the IPv6 Interface ID TLV.
The TLV value identifies the LDP P2MP LSP. It allows Ru to tunnel an
"inner" LDP P2MP LSP, the label for which is upstream assigned, over
an "outer" LDP P2MP LSP that has leaves <Rd1...Rdn>. The LDP P2MP LSP
IF_ID TLV allows Ru to signal to <Rd1...Rdn> the binding of the
inner LDP P2MP LSP to the outer LDP- P2MP LSP. The control plane
signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP uses
targeted LDP signaling messages
3. IP Multicast Tunnel TLV. Type = 30 (To be assigned by IANA) In
this case the TLV value is a <Source Address, Multicast Group
Address> tuple. Source Address is the IP address of the root of the
tunnel i.e. Ru, and Multicast Group Address is the Multicast Group
Address used by the tunnel. The addresses MUST be IPv4 addresses when
the IP Multicast Tunnel TLV is included in the IPv4 Interface ID TLV.
The addresses MUST be IPv6 addresses when the IP Multicast Tunnel TLV
is included in the IPv6 Interface ID TLV.
4. MPLS Context Label TLV. Type = 31 (To be assigned by IANA). In
this case the TLV value is a <Source Address, MPLS Context Label>
tuple. The Source Address belongs to Ru and the MPLS Context Label is
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
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
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
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 a MPLS label lookup on this label a combination of this label and
the incoming interface MUST be sufficient for <Rd1...Rdn> to 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.
skipping to change at page 10, line 33 skipping to change at page 12, line 44
- RSVP-TE P2MP LSP TLV (requested value 28) - RSVP-TE P2MP LSP TLV (requested value 28)
- LDP P2MP LSP TLV (requested value 29) - LDP P2MP LSP TLV (requested value 29)
- IP Multicast Tunnel TLV (requested value 30) - IP Multicast Tunnel TLV (requested value 30)
- MPLS Context Label TLV (requested value 31) - MPLS Context Label TLV (requested value 31)
8. Security Considerations 8. Security Considerations
The security considerations discussed in RFC 5331 and RFC 5332 apply The security considerations discussed in RFC 5036, RFC 5331 and RFC
to this document. 5332 apply to this document.
More detailed discussion of security issues that are relevant in the More detailed discussion of security issues that are relevant in the
context of MPLS and GMPLS, including security threats, related context of MPLS and GMPLS, including security threats, related
defensive techniques, and the mechanisms for detection and reporting, defensive techniques, and the mechanisms for detection and reporting,
are discussed in "Security Framework for MPLS and GMPLS Networks are discussed in "Security Framework for MPLS and GMPLS Networks
[MPLS-SEC]. [MPLS-SEC].
9. Acknowledgements 9. Acknowledgements
Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and
Thomas Morin for their comments. The hashing algorithm used on LAN Thomas Morin for their comments. The hashing algorithm used on LAN
interfaces is taken from [MLDP]. Thanks to Loa Andersson and Adrian interfaces is taken from [MLDP]. Thanks to Loa Andersson and Adrian
Farrel for their comments on the IANA section. Farrel for their comments and review.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
Assignment and Context Specific Label Space", RFC5331 Assignment and Context Specific Label Space", RFC5331
[RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, March 1997 Levels.", Bradner, March 1997
[RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized
Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based
Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472,
January 2003. January 2003.
[RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471 January
2003.
[RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036. [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036.
10.2. Informative References
[RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors],
"Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875
[MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", draft-ietf-mpls-ldp-p2mp-08.txt Paths", draft-ietf-mpls-ldp-p2mp-08.txt
10.2. Informative References
[RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux, [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux,
"LDP Capabilities", RFC5561 "LDP Capabilities", RFC5561
[MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS
Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt
[RFC3032] E. Rosen et. al, "MPLS Label Stack Encoding", RFC 3032 [RFC3032] E. Rosen et. al, "MPLS Label Stack Encoding", RFC 3032
11. Author's Address 11. Author's Address
 End of changes. 22 change blocks. 
71 lines changed or deleted 166 lines changed or added

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