draft-ietf-mpls-ldp-upstream-05.txt   draft-ietf-mpls-ldp-upstream-06.txt 
Network Working Group R. Aggarwal Network Working Group R. Aggarwal
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: July 2010 Expiration Date: August 2010
J. L. Le Roux J. L. Le Roux
France Telecom France Telecom
January 29, 2010 February 25, 2010
MPLS Upstream Label Assignment for LDP MPLS Upstream Label Assignment for LDP
draft-ietf-mpls-ldp-upstream-05.txt draft-ietf-mpls-ldp-upstream-06.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 34 skipping to change at page 2, line 34
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 .............. 3 3 LDP Upstream Label Assignment Capability .............. 3
4 Distributing Upstream-Assigned Labels in LDP .......... 4 4 Distributing Upstream-Assigned Labels in LDP .......... 4
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 ................. 7 6 LDP Point-to-Multipoint LSPs on a LAN ................. 7
7 IANA Considerations ................................... 9 7 IANA Considerations ................................... 9
8 Acknowledgements ...................................... 9 8 Security Considerations ............................... 9
9 References ............................................ 10 9 Acknowledgements ...................................... 10
9.1 Normative References .................................. 10 10 References ............................................ 10
9.2 Informative References ................................ 10 10.1 Normative References .................................. 10
10 Author's Address ...................................... 11 10.2 Informative References ................................ 10
11 Author's Address ...................................... 11
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). These
skipping to change at page 3, line 39 skipping to change at page 3, line 39
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
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 [LDP-CAP]. 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 |
skipping to change at page 4, line 43 skipping to change at page 4, line 43
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label
This is a 20-bit label value as specified in [RFC3032] represented as This is a 20-bit label value as specified in [RFC3032] represented as
a 20-bit number in a 4 octet field. a 20-bit number in a 4 octet field.
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 [RFC3036] 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
messages. A LDP LSR MUST NOT send the Upstream Assigned Label messages. A 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 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 a 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" [RFC3036]. 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 a 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,
skipping to change at page 9, line 15 skipping to change at page 9, line 15
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
This document defines a new LDP Upstream Label Assignment Capability This document defines a new LDP Upstream Label Assignment Capability
Parameter. IANA is requested to assign the value 0x0507 to this Parameter. IANA is requested to assign the value 0x0507 to this
Parameter. Parameter.
This document defines a new LDP Upstream-Assigned Label Request TLV,
IANA is requested to assign the type value of this TLV.
This document defines a new LDP Upstream-Assigned Label TLV, IANA is This document defines a new LDP Upstream-Assigned Label TLV, IANA is
requested to assign the type value of this TLV. requested to assign the type value of 0x204 to this TLV.
This document defines a new LDP Upstream-Assigned Label Request TLV,
IANA is requested to assign the type value of 0x205 to this TLV.
This document defines four new Interface ID TLVs: This document defines four new Interface ID TLVs:
- RSVP-TE P2MP LSP TLV - RSVP-TE P2MP LSP TLV
- LDP P2MP LSP TLV - LDP P2MP LSP TLV
- IP Multicast Tunnel TLV - IP Multicast Tunnel TLV
- MPLS Context Label TLV - MPLS Context Label TLV
IANA is requested to assign the type values of these TLVs. These values are assigned from the Interface_ID Type space defined in
[RFC3471]. IANA is requested to assign the type value 6 to RSVP-TE
P2MP LSP TLV, type value 7 to LDP P2MP LSP TLV, type value 8 to IP
Multicast Tunnel TLV and type value 9 to MPLS Context Label TLV.
8. Acknowledgements 8. Security Considerations
The security considerations discussed in RFC 5331 and RFC 5332 apply
to this document.
More detailed discussion of security issues that are relevant in the
context of MPLS and GMPLS, including security threats, related
defensive techniques, and the mechanisms for detection and reporting,
are discussed in "Security Framework for MPLS and GMPLS Networks
[MPLS-SEC].
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]. interfaces is taken from [MLDP].
9. References 10. References
9.1. Normative References
[RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 10.1. Normative References
RFC 3031.
[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 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471 January Switching (GMPLS) Signaling Functional Description", RFC 3471 January
2003. 2003.
[RFC3036] L. Andersson, et. al., "LDP Specification", January 2001. [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036.
9.2. Informative References
[MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", 10.2. Informative References
draft-ietf-l3vpn-2547bis-mcast-08.txt
[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 Label Switched Paths", draft-etf-mpls-ldp- Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
p2mp-07.txt Paths", draft-ietf-mpls-ldp-p2mp-08.txt
[LDP-CAP] B. Thomas, et. al., "LDP Capabilities", draft-thomas-mpls- [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux,
ldp-capabilities-04.txt "LDP Capabilities", RFC5561
10. Author's Address [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS
Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt
[RFC3032] E. Rosen et. al, "MPLS Label Stack Encoding", RFC 3032
11. 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: rahul@juniper.net
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
 End of changes. 19 change blocks. 
34 lines changed or deleted 46 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/