draft-ietf-mpls-ldp-upstream-10.txt   rfc6389.txt 
Network Working Group R. Aggarwal Internet Engineering Task Force (IETF) R. Aggarwal
Internet Draft Juniper Networks Request for Comments: 6389 Juniper Networks
Category: Standards Track Category: Standards Track JL. Le Roux
Expiration Date: August 2011 ISSN: 2070-1721 Orange
J. L. Le Roux November 2011
France Telecom
February 02, 2011
MPLS Upstream Label Assignment for LDP MPLS Upstream Label Assignment for LDP
draft-ietf-mpls-ldp-upstream-10.txt Abstract
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This document describes procedures for distributing upstream-assigned
provisions of BCP 78 and BCP 79. labels for the Label Distribution Protocol (LDP). It also describes
how these procedures can be used for avoiding branch Label Switching
Router (LSR) traffic replication on a LAN for LDP point-to-multipoint
(P2MP) Label Switched Paths (LSPs).
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
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 This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6389.
Copyright and License Notice Copyright Notice
Copyright (c) 2011 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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
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
This document describes procedures for distributing upstream-assigned
labels for Label Distribution Protocol (LDP). It also describes how
these procedures can be used for avoiding branch Label Switching
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. Introduction ....................................................3
2 Introduction .......................................... 3 2. Specification of Requirements ...................................3
3 LDP Upstream Label Assignment Capability .............. 4 3. LDP Upstream Label Assignment Capability ........................3
4 Distributing Upstream-Assigned Labels in LDP .......... 5 4. Distributing Upstream-Assigned Labels in LDP ....................4
4.1 Procedures ............................................ 5 4.1. Procedures .................................................4
5 LDP Tunnel Identifier Exchange ........................ 6 5. LDP Tunnel Identifier Exchange ..................................5
6 LDP Point-to-Multipoint LSPs on a LAN ................. 10 6. LDP Point-to-Multipoint LSPs on a LAN ...........................9
7 IANA Considerations ................................... 12 7. IANA Considerations ............................................11
7.1 LDP TLVs .............................................. 12 7.1. LDP TLVs ..................................................11
7.2 Interface Type Identifiers ............................ 12 7.2. Interface Type Identifiers ................................11
8 Security Considerations ............................... 12 8. Security Considerations ........................................12
9 Acknowledgements ...................................... 13 9. Acknowledgements ...............................................12
10 References ............................................ 13 10. References ....................................................12
10.1 Normative References .................................. 13 10.1. Normative References .....................................12
10.2 Informative References ................................ 13 10.2. Informative References ...................................13
11 Author's Address ...................................... 14
1. Specification of requirements
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 [RFC2119].
2. Introduction 1. Introduction
This document describes procedures for distributing upstream-assigned This document describes procedures for distributing upstream-assigned
labels [RFC5331] for Label Distribution Protocol (LDP) [RFC5036]. labels [RFC5331] for Label Distribution Protocol (LDP) [RFC5036].
These procedures follow the architecture for MPLS Upstream Label These procedures follow the architecture for MPLS upstream label
Assignment described in [RFC5331]. assignment described in [RFC5331].
This document describes extensions to LDP that a Label Switching This document describes extensions to LDP that a Label Switching
Router (LSR) can use to advertise to its neighboring LSRs whether the Router (LSR) can use to advertise whether the LSR supports upstream
LSR supports upstream label assignment. label assignment to its neighboring LSRs.
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 to avoid branch
branch LSR traffic replication on a LAN for LDP point-to-multipoint LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)
(P2MP) Label Switched Paths (LSPs) [MLDP] is also described. Label Switched Paths (LSPs) [RFC6388] is also described.
3. LDP Upstream Label Assignment Capability 2. Specification of Requirements
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 [RFC2119].
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 an 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| Upstrm Lbl Ass Cap(0x0507)| Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved | |1| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
If an 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 in LDP initialization Capability Parameter MUST be carried only in LDP Initialization
messages 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 an 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|Upstrm-Ass Lbl Req (0x0205)| 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
signal an upstream-assigned label. Upstream-Assigned Label TLVs are signal an upstream-assigned label. Upstream-Assigned Label TLVs are
carried by the messages used to advertise, release and withdraw carried by the messages used to advertise, release, and withdraw
upstream assigned label mappings. upstream-assigned label mappings.
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| Upstrm-Ass Label (0x0204) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | | Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Label field is a 20-bit label value as specified in [RFC3032] The Label field is a 20-bit label value as specified in [RFC3032],
represented as a 20-bit number in a 4 octet field as specified in represented as a 20-bit number in a 4-octet field as specified in
section 3.4.2.1 of RFC5036 [RFC5036]. Section 3.4.2.1 of RFC 5036 [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 An 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 has not previously advertised
the Upstream Label Assignment Capability in its LDP Initialization the Upstream Label Assignment Capability in its LDP Initialization
messages. A LDP LSR MUST NOT send the Upstream Assigned Label messages. An LDP LSR MUST NOT send the Upstream-Assigned Label
Request TLV to a neighboring LSR if the neighboring LSR had not Request TLV to a neighboring LSR if the neighboring LSR has 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 an 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. An LSR that generates an upstream-assigned label
to a neighbor LSR, for a given FEC, MUST NOT send a downstream label request to a neighbor LSR, for a given FEC, MUST NOT send a
mapping to the neighbor LSR for that FEC unless it withdraws the downstream label mapping to the neighbor LSR for that FEC unless it
upstream-assigned label binding. Similarly if an LSR generates a withdraws the upstream-assigned label binding. Similarly, if an LSR
downstream assigned label request to a neighbor LSR, for a given FEC, generates a downstream-assigned label request to a neighbor LSR, for
it MUST NOT send an upstream label mapping to that LSR for that FEC, a given FEC, it MUST NOT send an upstream label mapping to that LSR
unless it aborts the downstream assigned label request. for that FEC, 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 an MPLS As described in [RFC5331], a specific upstream LSR (Ru) MAY transmit
packet, the top label of which (L) is upstream-assigned, to a an MPLS packet, the top label of which (L) is upstream assigned, to
downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In its downstream neighbor LSR (Rd). In this case, the fact that L is
this case the fact that L is upstream-assigned is determined by Rd by upstream assigned is determined by Rd by the tunnel on which the
the tunnel on which the packet is received. There must be a mechanism packet is received. There must be a mechanism for Ru to inform Rd
for Ru to inform Rd that a particular tunnel from Ru to Rd will be that a particular tunnel from Ru to Rd will be used by Ru for
used by Ru for transmitting MPLS packets with upstream-assigned MPLS 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/IPv6 Next/Previous Hop Address and the Logical Interface ID
in the Interface ID TLV SHOULD be set to 0 by the sender and ignored fields in the Interface ID TLV SHOULD be set to 0 by the sender and
by the receiver. The Length field indicates the total length of the ignored by the receiver. The Length field indicates the total length
TLV, i.e., 4 + the length of the value field in octets. A value of the TLV, i.e., 4 + the length of the Value field in octets. A
field whose length is not a multiple of four MUST be zero-padded so Value field whose length is not a multiple of four MUST be zero-
that the TLV is four- octet aligned. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Logical Interface ID (0) | | Logical Interface ID (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs | | Sub-TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Interface ID TLV has the following format: The IPv6 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 (0x082e) | Length | |0|0| Type (0x082e) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 -
LSPs, LDP P2MP LSPs, IP Multicast Tunnels and context labels. The Traffic Engineering (RSVP-TE) P2MP LSPs, LDP P2MP LSPs, IP Multicast
sub-TLV value in the sub-TLV acts as the tunnel identifier. Tunnels, and context labels. The sub-TLV value in the sub-TLV acts
as the tunnel identifier.
Following are the sub-TLVs that are introduced: The following sub-TLVs 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)
the TLV is the RSVP-TE P2MP LSP SESSION Object [RFC4875].
The value of the TLV is the RSVP-TE P2MP LSP SESSION Object
[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 (0x1c) | 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 (0x1c) | 28 | | Type (0x1c) | 28 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2MP ID | | P2MP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID | | MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
| | | |
| ....... | | ....... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This TLV identifies the RSVP-TE P2MP LSP. It allows Ru to tunnel an 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 "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 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 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 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 plane signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP
uses targeted LDP signaling messages uses targeted LDP signaling messages.
2. LDP P2MP LSP TLV. Type = 29 (To be assigned by IANA). Value of the 2. LDP P2MP LSP TLV (Type = 29)
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 The value of the TLV is the LDP P2MP FEC as defined in [RFC6388] and
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 has to be set as per the procedures in [RFC6388]. Here is the format
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ of the LDP P2MP FEC as defined in [RFC6388]:
|P2MP Type | Address Family | Address Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3
~ Root Node Address ~ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Length | Opaque Value ... | |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 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 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. 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 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 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. 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 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 inner LDP P2MP LSP, the label for which is upstream assigned, over an
an "outer" LDP P2MP LSP that has leaves <Rd1...Rdn>. The LDP P2MP LSP 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 IF_ID TLV allows Ru to signal to <Rd1...Rdn> the binding of the inner
inner LDP P2MP LSP to the outer LDP- P2MP LSP. The control plane LDP P2MP LSP to the outer LDP-P2MP LSP. The control-plane signaling
signaling between Ru and <Rd1...Rdn> for the inner P2MP LSP uses between Ru and <Rd1...Rdn> for the inner P2MP LSP uses targeted LDP
targeted LDP signaling messages signaling messages.
3. IP Multicast Tunnel TLV. Type = 30 (To be assigned by IANA) In 3. IP Multicast Tunnel TLV (Type = 30)
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 In this case, the TLV value is a <Source Address, Multicast Group
this case the TLV value is a <Source Address, MPLS Context Label> Address> tuple. Source Address is the IP address of the root of the
tuple. The Source Address belongs to Ru and the MPLS Context Label is tunnel (i.e., Ru), and Multicast Group Address is the Multicast Group
an upstream assigned label, assigned by Ru. The Source Address MUST Address used by the tunnel. The addresses MUST be IPv4 addresses
be set to an IPv4 address when the MPLS Context Label TLV is carried when the IP Multicast Tunnel TLV is included in the IPv4 Interface ID
in the IPv4 Interface ID TLV. The Source Address MUST be set to an TLV. The addresses MUST be IPv6 addresses when the IP Multicast
IPv6 address when the MPLS Context Label TLV is carried in the IPv6 Tunnel TLV is included in the IPv6 Interface ID TLV.
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 4. MPLS Context Label TLV (Type = 31)
assigned context label, assigned by Ru. When <Rd1...Rdn> perform
an MPLS label lookup on this label a combination of this label
and the incoming interface MUST be sufficient for <Rd1...Rdn> to
uniquely determine Ru's context specific label space to lookup
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
the top label on the label stack.
Currently the usage of the context label TLV is limited only to LDP In this case, the TLV value is a <Source Address, MPLS Context Label>
P2MP LSPs on a LAN as specified in the next section. The context tuple. The Source Address belongs to Ru and the MPLS Context Label
label TLV MUST NOT be used for any other purposes. 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:
Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP o The label pushed by Ru for the outer MPLS LSP is an upstream-
assigned context label, assigned by Ru. When <Rd1...Rdn>
perform an MPLS label lookup on this label, a combination of
this label and the incoming interface MUST be sufficient for
<Rd1...Rdn> to uniquely determine Ru's context-specific label
space to look up the next label on the stack. <Rd1...Rdn> MUST
receive the data sent by Ru with the context-specific label
assigned by Ru being the top label on the label stack.
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
Label TLV MUST NOT be used for any other purpose.
Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP,
the above procedures assume that Ru has a priori knowledge of all the the above procedures assume that Ru has a priori knowledge of all the
<Rd1, ... Rdn>. In the scenario where the outer P2MP LSP is signaled <Rd1, ... Rdn>. In the scenario where the outer P2MP LSP is signaled
using RSVP-TE, Ru can obtain this information from RSVP-TE. However, using RSVP-TE, Ru can obtain this information from RSVP-TE. However,
in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP
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] describes how to setup P2MP LSPs using LDP. On a LAN the [RFC6388] 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". An 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 an LSR Rd that receives the LDP P2MP FEC [MLDP] from its Consider an LSR Rd that receives the LDP P2MP FEC [RFC6388] from its
downstream LDP peer. Further the upstream interface to reach LSR Ru downstream LDP peer. Additionally, consider that the upstream
which is the next-hop to the P2MP LSP root address, Pr, in the LDP interface to reach LSR Ru that is the next hop to the P2MP LSP root
P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream- address (Pr) in the LDP P2MP FEC is a LAN interface (Li) and that Rd
assigned labels. In this case Rd instead of sending a Label Mapping and Ru support upstream-assigned labels. In this case, instead of
message as described in [MLDP] sends a Label Request message to Ru. sending a Label Mapping message as described in [RFC6388], Rd sends a
This Label Request message MUST contain an Upstream Assigned Label Label Request message to Ru. This Label Request message MUST contain
Request TLV. an Upstream-Assigned Label Request TLV.
On receiving this message, Ru sends back a Label Mapping message to On receiving this message, Ru sends back a Label Mapping message to
Rd 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 an 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 interface 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.1. 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
LAN interface, Li, [RFC5331] by a downstream LSR on the LAN. This the LAN interface (Li) by a downstream LSR on the LAN. This lookup
lookup enables the downstream LSR to determine the context specific enables the downstream LSR to determine the context-specific label
label space to lookup the inner label in. space in which to look up the inner label.
Note that <Rd1...Rdn> may have more than one equal cost next-hop on Note that <Rd1...Rdn> may have more than one equal-cost next hop on
the LAN to reach Pr. It MAY be desirable for all of them to send the the LAN to reach Pr. It MAY be desirable for all of them to send the
label request to the same upstream LSR and they MAY select one label request to the same upstream LSR and they MAY select one
upstream LSR using the following procedure: upstream LSR using the following procedure:
1. The candidate upstream LSRs are numbered from lower to higher IP 1. The candidate upstream LSRs are numbered from lower to higher IP
address address.
2. The following hash is performed: H = (Sum Opaque value) modulo N, 2. The following hash is performed: H = (Sum Opaque value) modulo N,
where N is the number of candidate upstream LSRs. Opaque value is where N is the number of candidate upstream LSRs. The Opaque
defined in [MLDP] and comprises the P2MP LSP identifier. value is defined in [RFC6388] and comprises the P2MP LSP
identifier.
3. The selected upstream LSR U is the LSR that has the number H. 3. The selected upstream LSR U is the LSR that has the number H.
This allows for load balancing of a set of LSPs among a set of This allows for load balancing of a set of LSPs among a set of
candidate upstream LSRs, while ensuring that on a LAN interface a candidate upstream LSRs, while ensuring that on a LAN interface, a
single upstream LSR is selected. It is also to be noted that the single upstream LSR is selected. It is also to be noted that the
procedures in this section can still be used by Rd and Ru if other procedures in this section can still be used by Rd and Ru if other
LSRs on the LAN do not support upstream label assignment. Ingress LSRs on the LAN do not support upstream label assignment. Ingress
replication and downstream label assignment will continue to be used replication and downstream label assignment will continue to be used
for LSRs that do not support upstream label assignment. for LSRs that do not support upstream label assignment.
7. IANA Considerations 7. IANA Considerations
7.1. LDP TLVs 7.1. LDP TLVs
IANA maintains a registry of LDP TLVs at the registry "Label IANA maintains a registry of LDP TLVs at the registry "Label
Distribution Protocol" in the sub-registry called "TLV Type Name Distribution Protocol" in the sub-registry called "TLV Type Name
Space". Space".
This document defines a new LDP Upstream Label Assignment Capability This document defines a new LDP Upstream Label Assignment Capability
TLV (Section 3). IANA is requested to assign the value 0x0507 to this TLV (Section 3). IANA has assigned the value 0x0507 to this TLV.
TLV.
This document defines a new LDP Upstream-Assigned Label TLV (Section This document defines a new LDP Upstream-Assigned Label TLV (Section
4). IANA is requested to assign the type value of 0x204 to this TLV. 4). IANA has assigned the type value of 0x204 to this TLV.
This document defines a new LDP Upstream-Assigned Label Request TLV This document defines a new LDP Upstream-Assigned Label Request TLV
(Section 4). IANA is requested to assign the type value of 0x205 to (Section 4). IANA has assigned the type value of 0x205 to this TLV.
this TLV.
7.2. Interface Type Identifiers 7.2. Interface Type Identifiers
[RFC3472] defines the LDP Interface ID IPv4 and IPv6 TLV. These top- [RFC3472] defines the LDP Interface ID IPv4 and IPv6 TLV. These top-
level TLVs can carry sub-TLVs dependent on the interface type. These level TLVs can carry sub-TLVs dependent on the interface type. These
sub-TLVs are assigned "Interface ID Types". IANA maintains a registry sub-TLVs are assigned "Interface ID Types". IANA maintains a
of Interface ID Types for use in GMPLS in the registry "Generalized registry of Interface ID Types for use in GMPLS in the registry
Multi-Protocol Label Switching (GMPLS) Signaling Parameters" and sub- "Generalized Multi-Protocol Label Switching (GMPLS) Signaling
registry "Interface_ID Types". IANA is requested to make Parameters" and sub-registry "Interface_ID Types". IANA has made the
corresponding allocations from this registry as follows: corresponding allocations from this registry as follows:
- RSVP-TE P2MP LSP TLV (requested value 28) - RSVP-TE P2MP LSP TLV (value 28)
- LDP P2MP LSP TLV (requested value 29) - LDP P2MP LSP TLV (value 29)
- IP Multicast Tunnel TLV (requested value 30) - IP Multicast Tunnel TLV (value 30)
- MPLS Context Label TLV (requested value 31) - MPLS Context Label TLV (value 31)
8. Security Considerations 8. Security Considerations
The security considerations discussed in RFC 5036, RFC 5331 and RFC The security considerations discussed in [RFC5036], [RFC5331], and
5332 apply to this document. [RFC5332] 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"
[RFC5920].
[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
Thomas Morin for their comments. The hashing algorithm used on LAN and Thomas Morin for their comments. The hashing algorithm used on
interfaces is taken from [MLDP]. Thanks to Loa Andersson, Adrian LAN interfaces is taken from [RFC6388]. Thanks to Loa Andersson,
Farrel and Eric Rosen for their comments and review. Adrian Farrel, and Eric Rosen 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Assignment and Context Specific Label Space", RFC5331 Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa,
Levels.", Bradner, March 1997 Ed., "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
Label Assignment and Context-Specific Label Space", RFC
5331, August 2008.
[RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], [RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter,
"Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 "MPLS Multicast Encapsulations", RFC 5332, August 2008.
[MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Le Roux, "LDP Capabilities", RFC 5561, July 2009.
Paths", draft-ietf-mpls-ldp-p2mp-08.txt
10.2. Informative References [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
[RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux, 10.2. Informative References
"LDP Capabilities", RFC5561
[MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3032] E. Rosen et. al, "MPLS Label Stack Encoding", RFC 3032 [RFC3472] Ashwood-Smith, P., Ed., and L. Berger, Ed., "Generalized
Multi-Protocol Label Switching (GMPLS) Signaling
Constraint-based Routed Label Distribution Protocol
(CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based Networks", RFC 5920, July 2010.
Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472,
January 2003.
11. Author's Address Author's Address
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Phone: +1-408-936-2720 Phone: +1-408-936-2720
Email: rahul@juniper.net EMail: raggarwa_1@yahoo.com
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
France France
E-mail: jeanlouis.leroux@orange-ftgroup.com EMail: jeanlouis.leroux@orange-ftgroup.com
 End of changes. 114 change blocks. 
330 lines changed or deleted 329 lines changed or added

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