draft-ietf-mpls-upstream-label-00.txt   draft-ietf-mpls-upstream-label-01.txt 
Network Working Group R. Aggarwal Network Working Group R. Aggarwal
Internet Draft Juniper Networks Internet Draft Juniper Networks
Expiration Date: August 2006
Y. Rekhter Y. Rekhter
Juniper Networks Juniper Networks
E. Rosen E. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
February 2006 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-00.txt draft-ietf-mpls-upstream-label-01.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 3, line 49 skipping to change at page 4, line 4
a FEC F for a LSP LSP1. The LSR that assigns the label distributes a FEC F for a LSP LSP1. The LSR that assigns the label distributes
the binding and context to a LSR Lr that then receives MPLS packets the binding and context to a LSR Lr that then receives MPLS packets
on LSP1 with label L. When Lr receives a MPLS packet on LSP1 it MUST on LSP1 with label L. When Lr receives a MPLS packet on LSP1 it MUST
be able to determine the context of this packet. be able to determine the context of this packet.
An example of such a context is a Tunnel over which MPLS packets on An example of such a context is a Tunnel over which MPLS packets on
LSP1 may be received and in this case the top label of the MPLS LSP1 may be received and in this case the top label of the MPLS
packet is looked up in a "Tunnel Specific Label Space". This does packet is looked up in a "Tunnel Specific Label Space". This does
imply that Lr be able to determine the tunnel over which the packet imply that Lr be able to determine the tunnel over which the packet
was received. If the tunnel is a MPLS tunnel, penultimate-hop-popping was received. If the tunnel is a MPLS tunnel, penultimate-hop-popping
(PHP) must be disabled for the tunnel. Another example of such a con- (PHP) must be disabled for the tunnel. Another example of such a
text is the neighbor from which MPLS packets on LSP1 may be received context is the neighbor from which MPLS packets on LSP1 may be
and in this case the top label of the MPLS packet is looked up in a received and in this case the top label of the MPLS packet is looked
"Neighbor Specific Label Space". These are further described in sec- up in a "Neighbor Specific Label Space". These are further described
tion 7. in section 7.
There may be other sorts of contexts as well. For instance, we define There may be other sorts of contexts as well. For instance, we define
the notion of a MPLS label being used to establish a context, i.e. the notion of a MPLS label being used to establish a context, i.e.
identify a label space. identify a label space.
4. Upstream Label Assignment 4. Upstream Label Assignment
When two MPLS LSRs are adjacent in a MPLS label switched path (LSP) When two MPLS LSRs are adjacent in a MPLS label switched path (LSP)
one of them can be termed an "upstream LSR" and the other a "down- one of them can be termed an "upstream LSR" and the other a
stream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have agreed "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have
to bind Label L to a Forwarding Equivalence Class (FEC), F, for pack- agreed to bind Label L to a Forwarding Equivalence Class (FEC), F,
ets sent from Ru to Rd. Then with respect to this binding, Ru is the for packets sent from Ru to Rd. Then with respect to this binding,
"upstream LSR", and Rd is the "downstream LSR"." Ru is the "upstream LSR", and Rd is the "downstream LSR"."
When the label binding for F is first made by Rd and distributed by When the label binding for F is first made by Rd and distributed by
Rd to Ru, the binding is said to be "downstream assigned". When Rd to Ru, the binding is said to be "downstream assigned". When
the label binding for F is first made by Ru and distributed by Ru the label binding for F is first made by Ru and distributed by Ru
to Rd, the binding is said to be "upstream assigned". to Rd, the binding is said to be "upstream assigned".
An important observation is that the downstream LSR Rd that receives An important observation is that the downstream LSR Rd that receives
MPLS packets with a top label L is not the LSR that assigns and dis- MPLS packets with a top label L is not the LSR that assigns and
tributes label L. Rd must use a context-specific label space to distributes label L. Rd must use a context-specific label space to
lookup label L as described in section 7. lookup label L as described in section 7.
4.1. Upstream Assigned and Downstream Assigned Labels 4.1. Upstream Assigned and Downstream Assigned Labels
It is possible that some LSRs on a LSP for FEC F, distribute down- It is possible that some LSRs on a LSP for FEC F, distribute
stream assigned label bindings for FEC F, while other LSRs distribute downstream assigned label bindings for FEC F, while other LSRs
upstream assigned label bindings. It is possible for a LSR to dis- distribute upstream assigned label bindings. It is possible for a LSR
tribute a downstream assigned label binding for FEC F to its upstream to distribute a downstream assigned label binding for FEC F to its
adjacent LSR AND distribute an upstream assigned label binding for upstream adjacent LSR AND distribute an upstream assigned label
FEC F to its downstream adjacent LSR. Two adjacent LSRs for a LSP binding for FEC F to its downstream adjacent LSR. Two adjacent LSRs
that is bound to FEC F, MUST use either downstream assigned label for a LSP that is bound to FEC F, MUST use either downstream assigned
distribution or upstream assigned label distribution, for FEC F, but label distribution or upstream assigned label distribution, for FEC
NOT both. How these LSRs will determine which of the two is to be F, but NOT both. How these LSRs will determine which of the two is to
used is outside the scope of this document. be used is outside the scope of this document.
5. Assigning Upstream Assigned Labels 5. Assigning Upstream Assigned Labels
The only requirement on an upstream LSR assigning upstream assigned The only requirement on an upstream LSR assigning upstream assigned
labels is that an upstream assigned label must be unambiguous in the labels is that an upstream assigned label must be unambiguous in the
context-specific label space in which the downstream LSR will look it context-specific label space in which the downstream LSR will look it
up. An upstream LSR which is the head end of multiple tunnels SHOULD up. An upstream LSR which is the head end of multiple tunnels SHOULD
by default assign the upstream-assigned labels from a single label by default assign the upstream-assigned labels from a single label
space which is common to all those tunnels. Further an upstream LSR space which is common to all those tunnels. Further an upstream LSR
which is the head of multiple tunnels SHOULD use the same IP address which is the head of multiple tunnels SHOULD use the same IP address
as the head identifier of these tunnels, provided that the head iden- as the head identifier of these tunnels, provided that the head
tifier of these tunnels is an IP address. The LSR could assign the identifier of these tunnels is an IP address. The LSR could assign
same label value to both a downstream-assigned and an upstream- the same label value to both a downstream-assigned and an upstream-
assigned label. The downstream LSR always looks up upstream assigned assigned label. The downstream LSR always looks up upstream assigned
MPLS labels in a context-specific label space as described in section MPLS labels in a context-specific label space as described in section
7. 7.
An entry for the upstream assigned labels is not created in the An entry for the upstream assigned labels is not created in the
Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these
labels are not incoming labels. Instead an upstream label is an out- labels are not incoming labels. Instead an upstream label is an
going label, with respect to the upstream LSR, for MPLS packets outgoing label, with respect to the upstream LSR, for MPLS packets
transmitted on the MPLS LSP in which the upstream LSR is adjacent to transmitted on the MPLS LSP in which the upstream LSR is adjacent to
the downstream LSR. Hence an upstream label is part of a Next Hop the downstream LSR. Hence an upstream label is part of a Next Hop
Label Forwarding Entry (NHLFE) at the upstream LSR. Label Forwarding Entry (NHLFE) at the upstream LSR.
When Ru advertises a binding of label L for FEC F to Rd, it creates a When Ru advertises a binding of label L for FEC F to Rd, it creates a
NHLFE entry corresponding to L. This NHLFE entry results in imposing NHLFE entry corresponding to L. This NHLFE entry results in imposing
the label L on the MPLS label stack of the packet forwarded using the the label L on the MPLS label stack of the packet forwarded using the
NHLFE entry. If Ru is a transit router on the LSP for FEC F, it NHLFE entry. If Ru is a transit router on the LSP for FEC F, it
binds the ILM for the LSP to this NHLFE. If Ru is an ingress router binds the ILM for the LSP to this NHLFE. If Ru is an ingress router
on the LSP for FEC F, it binds the FEC to the NHLFE entry. on the LSP for FEC F, it binds the FEC to the NHLFE entry.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
context-specific label space, not in a per-platform label space. context-specific 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 MPLS packets received from Ru, the top
label of which is upstream assigned by Ru. label of which is upstream assigned by Ru.
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 "con- of a received MPLS packet is upstream assigned and if yes, the
text" of this packet. How this determination is made depends on the "context" of this packet. How this determination is made depends on
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. Ru may transmit this packet to
Rd by encapsulating it directly in a data link frame or by transmit- Rd by encapsulating it directly in a data link frame or by
ting it in an IP or MPLS tunnel. transmitting it in an IP or MPLS tunnel.
If Ru transmits this packet by encapsulating it in a data link frame, If Ru transmits this packet by encapsulating it in a data link frame,
then whether L is upstream assigned or downstream assigned is deter- then whether L is upstream assigned or downstream assigned is
mined by Rd as described in [MPLS-MCAST-ENCAPS]. If L is upstream determined by Rd as described in [MPLS-MCAST-ENCAPS]. If L is
assigned then [MPLS-MCAST-ENCAPS] uses a different ether type in the upstream assigned then [MPLS-MCAST-ENCAPS] uses a different ether
data link frame. Rd maintains a separate "Upstream Neighbor Label type in the data link frame. Rd maintains a separate "Upstream
Space" for Ru. The "context" of this packet i.e. the upstream neigh- Neighbor Label Space" for Ru. The "context" of this packet i.e. the
bor label space, in which L was reserved is determined by the data upstream neighbor label space, in which L was reserved is determined
link header. For example if the data link header is ethernet, the by the data link header. For example if the data link header is
source MAC address is used to determine the context. ethernet, the source MAC address is used to determine the context.
If Ru transmits this packet by encapsulating it in an IP or MPLS tun- If Ru transmits this packet by encapsulating it in an IP or MPLS
nel, then the fact that L is upstream assigned is determined by Rd by tunnel, then the fact that L is upstream assigned is determined by Rd
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
such a tunnel, it determines the "context" of this packet based on such a tunnel, it determines the "context" of this packet based on
the tunnel that the packet is received on. the tunnel that the packet is received on.
Rd may maintain a separate "Tunnel Label Space" for the tunnel or it Rd may maintain a separate "Tunnel Label Space" for the tunnel or it
skipping to change at page 8, line 12 skipping to change at page 8, line 12
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 9. References
9.1. Normative References 9.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 Lev- [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-rosen-mpls-codepoint-00.txt draft-ietf-mpls-codepoint-00.txt
9.2. Informative References 9.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"
10. Author Information 10. Author Information
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
skipping to change at page 9, line 16 skipping to change at page 9, line 16
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.
Copies of IPR disclosures made to the IETF Secretariat and any assur- Copies of IPR disclosures made to the IETF Secretariat and any
ances of licenses to be made available, or the result of an attempt assurances of licenses to be made available, or the result of an
made to obtain a general license or permission for the use of such attempt made to obtain a general license or permission for the use of
proprietary rights by implementers or users of this specification can such proprietary rights by implementers or users of this
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 12. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as 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 AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 17 change blocks. 
53 lines changed or deleted 52 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/