draft-ietf-mpls-upstream-label-01.txt   draft-ietf-mpls-upstream-label-02.txt 
Network Working Group R. Aggarwal Network Working Group R. Aggarwal
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: September 2007
Y. Rekhter Y. Rekhter
Juniper Networks Juniper Networks
E. Rosen E. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
December 2006
MPLS Upstream Label Assignment and Context Specific Label Space MPLS Upstream Label Assignment and Context Specific Label Space
draft-ietf-mpls-upstream-label-01.txt draft-ietf-mpls-upstream-label-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of 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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1 Specification of requirements ......................... 2 1 Specification of requirements ......................... 2
2 Introduction .......................................... 2 2 Introduction .......................................... 2
3 Context-Specific Label Space .......................... 3 3 Context-Specific Label Space .......................... 3
4 Upstream Label Assignment ............................. 4 4 Upstream Label Assignment ............................. 4
4.1 Upstream Assigned and Downstream Assigned Labels ...... 4 4.1 Upstream Assigned and Downstream Assigned Labels ...... 4
5 Assigning Upstream Assigned Labels .................... 5 5 Assigning Upstream Assigned Labels .................... 5
6 Distributing Upstream Assigned Labels ................. 5 6 Distributing Upstream Assigned Labels ................. 5
7 Upstream Neighbor Label Space and Tunnel Label Space .. 6 7 Upstream Neighbor Label Space and Tunnel Label Space .. 6
8 Usage of Upstream Assigned Labels ..................... 7 8 Context Label on LANs ................................. 7
9 References ............................................ 8 9 Usage of Upstream Assigned Labels ..................... 8
9.1 Normative References .................................. 8 10 Acknowledgements ...................................... 8
9.2 Informative References ................................ 8 11 References ............................................ 9
10 Author Information .................................... 8 11.1 Normative References .................................. 9
11 Intellectual Property Statement ....................... 9 11.2 Informative References ................................ 9
12 Full Copyright Statement .............................. 9 12 Author Information .................................... 9
13 Intellectual Property Statement ....................... 10
14 Full Copyright Statement .............................. 10
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
RFC 3031 [RFC3031] limits the MPLS architecture to downstream RFC 3031 [RFC3031] limits the MPLS architecture to downstream
skipping to change at page 6, line 13 skipping to change at page 6, line 13
LSR for FEC F, or (b) if it has already received an upstream label LSR for FEC F, or (b) if it has already received an upstream label
binding for that FEC from its adjacent upstream LSR for FEC F, or (c) binding for that FEC from its adjacent upstream LSR for FEC F, or (c)
if it has received a request for a downstream label binding from its if it has received a request for a downstream label binding from its
upstream adjacent LSR. In the latter case each LSR, upon noting that upstream adjacent LSR. In the latter case each LSR, upon noting that
it recognizes a particular FEC, makes an independent decision to bind it recognizes a particular FEC, makes an independent decision to bind
an upstream-assigned label to that FEC and to distribute that binding an upstream-assigned label to that FEC and to distribute that binding
to its label distribution peers. to its label distribution peers.
7. Upstream Neighbor Label Space and Tunnel Label Space 7. Upstream Neighbor Label Space and Tunnel Label Space
If the top label of an MPLS packet is upstream assigned, when the If the top label of a MPLS packet being processed by LSR Rd is
packet is received by LSR Rd the label is looked up in a upstream assigned, the label is looked up in a context-specific
context-specific label space, not in a per-platform label space. label space, not in a per-platform label space.
Rd uses a context-specific label space that it maintains for Ru to Rd uses a context-specific label space that it maintains for Ru to
"reserve" MPLS labels assigned by Ru. Hence if Ru distributes an "reserve" MPLS labels assigned by Ru. Hence if Ru distributes an
upstream assigned label binding L for FEC F to Rd, then Rd reserves L upstream assigned label binding L for FEC F to Rd, then Rd reserves L
in the separate ILM for Ru's context-specific label space. This is in the separate ILM for Ru's context-specific label space. This is
the ILM that Rd uses to lookup MPLS packets received from Ru, the top the ILM that Rd uses to lookup a MPLS label which is upstream
label of which is upstream assigned by Ru. assigned by Ru. This label may be the top label on the label stack of
a packet received from Ru or it may be exposed as the top label on
the label stack as a result of Rd processing such a packet.
This implies that Rd MUST be able to determine whether the top label This implies that Rd MUST be able to determine whether the top label
of a received MPLS packet is upstream assigned and if yes, the of a MPLS packet being processed is upstream assigned and if yes, the
"context" of this packet. How this determination is made depends on "context" of this packet. How this determination is made depends on
the mechanism that is used by Ru to transmit the MPLS packet with an the mechanism that is used by Ru to transmit the MPLS packet with an
upstream assigned top label L, to Rd. Ru may transmit this packet to upstream assigned top label L, to Rd.
Rd by encapsulating it directly in a data link frame or by
transmitting it in an IP or MPLS tunnel.
If Ru transmits this packet by encapsulating it in a data link frame,
then whether L is upstream assigned or downstream assigned is
determined by Rd as described in [MPLS-MCAST-ENCAPS]. If L is
upstream assigned then [MPLS-MCAST-ENCAPS] uses a different ether
type in the data link frame. Rd maintains a separate "Upstream
Neighbor Label Space" for Ru. The "context" of this packet i.e. the
upstream neighbor label space, in which L was reserved is determined
by the data link header. For example if the data link header is
ethernet, the source MAC address is used to determine the context.
If Ru transmits this packet by encapsulating it in an IP or MPLS If Ru transmits this packet by encapsulating it in an IP or MPLS
tunnel, then the fact that L is upstream assigned is determined by Rd tunnel, then the fact that L is upstream assigned is determined by Rd
by the tunnel on which the packet is received. A given tunnel can be by the tunnel on which the packet is received. A given tunnel can be
used for transmitting either downstream assigned MPLS packets or used for transmitting either downstream assigned MPLS packets or
upstream assigned MPLS packets, or both. There must be a mechanism upstream assigned MPLS packets, or both. There must be a mechanism
for Ru to inform Rd that a particular tunnel from Ru to Rd will be for Ru to inform Rd that a particular tunnel from Ru to Rd will be
used by Ru for transmitting MPLS packets with upstream assigned MPLS used by Ru for transmitting MPLS packets with upstream assigned MPLS
labels. The description of such a mechanism is outside the scope of labels. The description of such a mechanism is outside the scope of
this document. When Rd receives MPLS packets with a top label L on this document. When Rd receives MPLS packets with a top label L on
skipping to change at page 7, line 26 skipping to change at page 7, line 16
a MPLS tunnel, then Rd determines a) That L is upstream assigned and a MPLS tunnel, then Rd determines a) That L is upstream assigned and
b) The context for L, from the labels above L in the label stack. b) The context for L, from the labels above L in the label stack.
Note that one or more of these labels may also be upstream assigned Note that one or more of these labels may also be upstream assigned
labels. labels.
If the tunnel on which Rd receives MPLS packets with a top label L is If the tunnel on which Rd receives MPLS packets with a top label L is
an IP/GRE tunnel then Rd determines a) That L is upstream assigned an IP/GRE tunnel then Rd determines a) That L is upstream assigned
[MPLS-MCAST-ENCAPS] and b) The context for L, from the source address [MPLS-MCAST-ENCAPS] and b) The context for L, from the source address
in the IP header. in the IP header.
8. Usage of Upstream Assigned Labels When Ru and Rd are adjacent to each other on a multi-access data link
media, if Ru would transmit the packet, with top label L, by
encapsulating it in a data link frame, then whether L is upstream
assigned or downstream assigned can be determined by Rd as described
in [MPLS-MCAST-ENCAPS]. This is because if L is upstream assigned
then [MPLS-MCAST-ENCAPS] uses a different ether type in the data link
frame. However this is not sufficient for Rd to determine the context
of this packet. In order for Rd to determine the context of this
packet, Ru encapsulates the packet, in a one hop MPLS tunnel. This
tunnel uses an MPLS context label that is assigned by Ru. Section 8
describes how the context label is assigned. Rd maintains a separate
"Upstream Neighbor Label Space" for Ru. The "context" of this packet,
i.e. Ru's upstream neighbor label space, in which L was reserved, is
determined by Rd from the top context label and the interface on
which the packet is received. The ether type in the data link frame
is set to indicate that the top label is upstream assigned. The
second label in the stack is L.
8. Context Label on LANs
The procedure described below applies to LSRs using IPv4 and does not
apply to LSRs only using IPv6. A solution for IPv6 LSRs is outside
the scope of this document.
For a labeled packet with an ether type of 'upstream label
assignment' the top label is used as the context. The context label
value is assigned by the upstream LSR and advertised to the
downstream LSRs. Mechanisms for advertising the context label are
outside the scope of this document.
The context label assigned by a LSR on a LAN interface MUST be unique
across all the context labels assigned by other LSRs on the same LAN.
Each LAN interface is normally configured with a primary IPv4 address
that is unique on that LAN. The host part of the IPv4 address,
identified by the network mask, is unique. If the IPv4 network mask
is greater then 12 bits, it is possible to map the remaining 20 bits
into an unique context label value. This enables the LSRs on the LAN
to assign an unique context label without the need for additional
configuration. To avoid assigning context label values that fall into
the reserved label space range [RFC 3032], the value of the host is
offset with 0x10 if the host is not greater then 0xFFFEF. Host values
greater then 0xFFFEF are not allowed to be used as the context label.
Consider LSRs Rm (middle) connected to Ru (upstream) on a LAN
interface and to Rd (downstream) on a different LAN interface. Rm
could receive a context label value derived from the LAN interface
from Rd and from Ru. It is possible that the context label values
used by Ru and Rd are the same. This would occur if the LAN
interfaces of both Ru and Rd are configured with a primary IPv4
address where the lowest 20 bits are equal. To avoid these conflicts
the context label MUST be looked up in the context of the LAN
interface identifier on which the packet is received. A receiving LSR
that receives a packet with a context label of Lc over LAN interface
identified by X, MUST use the label space specific to X to lookup Lc.
This determines the context to lookup the label below Lc on the label
stack.
9. Usage of Upstream Assigned Labels
A typical usage of upstream assigned labels is when an upstream LSR A typical usage of upstream assigned labels is when an upstream LSR
Ru is adjacent to more than downstream LSRs <Rd1...Rdn> in a LSP LSP1 Ru is adjacent to more than downstream LSRs <Rd1...Rdn> in a LSP LSP1
AND Ru is connected to <Rd1...Rdn> via a multi-access media or tunnel AND Ru is connected to <Rd1...Rdn> via a multi-access media or tunnel
AND Ru wants to transmit a single copy of a MPLS packet on the LSP to AND Ru wants to transmit a single copy of a MPLS packet on the LSP to
<Rd1...Rdn>. In this case Ru can distribute an upstream assigned <Rd1...Rdn>. In this case Ru can distribute an upstream assigned
label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit label L that is bound to the FEC for LSP1, to <Rd1..Rdn> and transmit
a MPLS packet, the top label of which is L, on the multi-access media a MPLS packet, the top label of which is L, on the multi-access media
or tunnel. Each of <Rd1..Rdn> will then interpret this MPLS packet in or tunnel. Each of <Rd1..Rdn> will then interpret this MPLS packet in
the context of Ru and forward it appropriately. This implies that the context of Ru and forward it appropriately. This implies that
<Rd1..Rdn> MUST all be able to support an Upstream Neighbor Label <Rd1..Rdn> MUST all be able to support an Upstream Neighbor Label
Space for Ru and Ru MUST be able to determine this. The mechanisms Space for Ru and Ru MUST be able to determine this. The mechanisms
for determining this are specific to the application that is using for determining this are specific to the application that is using
upstream assigned labels and is outside the scope of this document. upstream assigned labels and is outside the scope of this document.
9. References 10. Acknowledgements
9.1. Normative References Thanks to IJsbrand Wijnands's contribution, specifically for the text
on which section 8 is based.
11. References
11.1. Normative References
[RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon,
RFC 3031. RFC 3031.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
[MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter,
draft-ietf-mpls-codepoint-00.txt draft-ietf-mpls-codepoint-01.txt
9.2. Informative References 11.2. Informative References
[MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs" [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs",
draft-ietf-l3vn-2547bis-mcast-02.txt
10. Author Information 12. Author Information
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: rahul@juniper.net Email: rahul@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: yakov@juniper.net Email: yakov@juniper.net
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
Email: erosen@cisco.com Email: erosen@cisco.com
11. Intellectual Property Statement 13. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 9, line 29 skipping to change at page 10, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
12. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007). This document is subject to the
to the rights, licenses and restrictions contained in BCP 78, and rights, licenses and restrictions contained in BCP 78, and except as
except as set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 19 change blocks. 
45 lines changed or deleted 99 lines changed or added

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