Internet DRAFT - draft-raggarwa-mpls-upstream-label
draft-raggarwa-mpls-upstream-label
Network Working Group R. Aggarwal
Internet Draft Juniper Networks
Expiration Date: April 2006
Y. Rekhter
Juniper Networks
E. Rosen
Cisco Systems, Inc.
October 2005
MPLS Upstream Label Assignment and Context Specific Label Space
draft-raggarwa-mpls-upstream-label-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
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
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
RFC 3031 limits the MPLS architecture to downstream assigned MPLS
labels. This document introduces the notion of upstream assigned
MPLS labels. It describes the procedures for upstream MPLS label
assignment and introduces the concept of a "Context-Specific Label
Space".
Raggarwa, Rekhter & Rosen [Page 1]
Internet Draft draft-raggarwa-mpls-upstream-label-01.txt October 2005
Table of Contents
1 Specification of requirements ......................... 2
2 Introduction .......................................... 2
3 Context-Specific Label Space .......................... 3
4 Upstream Label Assignment ............................. 4
4.1 Upstream Assigned and Downstream Assigned Labels ...... 4
5 Assigning Upstream Assigned Labels .................... 5
6 Distributing Upstream Assigned Labels ................. 5
7 Upstream Neighbor Label Space and Tunnel Label Space .. 6
8 Usage of Upstream Assigned Labels ..................... 7
9 References ............................................ 8
9.1 Normative References .................................. 8
9.2 Informative References ................................ 8
10 Author Information .................................... 8
11 Intellectual Property Statement ....................... 9
12 Full Copyright Statement .............................. 9
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
RFC 3031 [RFC3031] limits the MPLS architecture to downstream
assigned MPLS labels. To quote from RFC 3031:
"In the MPLS architecture, the decision to bind a particular label L
to a particular FEC F is made by the LSR which is DOWNSTREAM with
respect to that binding. The downstream LSR then informs the
upstream LSR of the binding. Thus labels are "downstream-assigned",
and label bindings are distributed in the "downstream to upstream"
direction."
MPLS upstream label assignment has been discussed and mentioned
before [RFC3353, MVPN]. However the architecture for MPLS upstream
label assignment and the associated procedures have not been
described. This document introduces the notion of upstream assigned
MPLS labels to the MPLS architecture. The procedures for upstream
Raggarwa, Rekhter & Rosen [Page 2]
Internet Draft draft-raggarwa-mpls-upstream-label-01.txt October 2005
MPLS label assignment are described.
RFC 3031 describes per-platform and per-interface label space. This
document generalizes the latter to a "Context-Specific Label Space"
and describes a "Neighbor Label Space" as an example of this.
Upstream assigned labels are always looked up in a context-specific
label space.
3. Context-Specific Label Space
RFC 3031 describes per-platform and per-interface label spaces. This
document introduces the more general concept of a "Context-Specific
Label Space". A LSR may contain one or more context-specific label
spaces. In general, labels are looked up in the per-platform label
space unless something about the context determines that a label be
looked up in a particular context-specific label space.
One example of a context-specific label space is the per-interface
label space discussed in RFC 3031. When a MPLS packet is received
over a particular interface the top label of the packet may need to
be looked up in the receiving interface's per-interface label space.
In this case the receiving interface determines the context of the
packet. Whether MPLS packets received over a particular interface
need to have their top labels looked up in a per-interface
label space depends on some characteristic or configuration of the
interface.
There may be more than one kind of context-specific label space.
Context-specific label spaces can be used for downstream assigned
labels or upstream assigned labels. Per-interface label space
[RFC3031] is an example of a context-specific label space used for
downstream assigned labels.
When MPLS labels are upstream assigned the context of a MPLS label L
is provided by the LSR that assigns the label and binds the label to
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
on LSP1 with label L. When Lr receives a MPLS packet on LSP1 it MUST
be able to determine the context of this packet.
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
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
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-
text is the neighbor from which MPLS packets on LSP1 may be received
Raggarwa, Rekhter & Rosen [Page 3]
Internet Draft draft-raggarwa-mpls-upstream-label-01.txt October 2005
and in this case the top label of the MPLS packet is looked up in a
"Neighbor Specific Label Space". These are further described in sec-
tion 7.
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.
identify a label space.
4. Upstream Label Assignment
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-
stream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have agreed
to bind Label L to a Forwarding Equivalence Class (FEC), F, for pack-
ets sent from Ru to Rd. Then with respect to this binding, 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
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
to Rd, the binding is said to be "upstream assigned".
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-
tributes label L. Rd must use a context-specific label space to
lookup label L as described in section 7.
4.1. Upstream Assigned and Downstream Assigned Labels
It is possible that some LSRs on a LSP for FEC F, distribute down-
stream assigned label bindings for FEC F, while other LSRs distribute
upstream assigned label bindings. It is possible for a LSR to dis-
tribute a downstream assigned label binding for FEC F to its upstream
adjacent LSR AND distribute an upstream assigned label binding for
FEC F to its downstream adjacent LSR. Two adjacent LSRs for a LSP
that is bound to FEC F, MUST use either downstream assigned label
distribution or upstream assigned label distribution, for FEC F, but
NOT both. How these LSRs will determine which of the two is to be
used is outside the scope of this document.
Raggarwa, Rekhter & Rosen [Page 4]
Internet Draft draft-raggarwa-mpls-upstream-label-01.txt October 2005
5. Assigning Upstream Assigned Labels
The only requirement on an upstream LSR assigning upstream assigned
labels is that an upstream assigned label must be unambiguous in the
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
by default assign the upstream-assigned labels from a single label
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
as the head identifier of these tunnels, provided that the head iden-
tifier of these tunnels is an IP address. The LSR could assign the
same label value to both a downstream-assigned and an upstream-
assigned label. The downstream LSR always looks up upstream assigned
MPLS labels in a context-specific label space as described in section
7.
An entry for the upstream assigned labels is not created in the
Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these
labels are not incoming labels. Instead an upstream label is an out-
going label, with respect to the upstream LSR, for MPLS packets
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
Label Forwarding Entry (NHLFE) at the upstream LSR.
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
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
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.
6. Distributing Upstream Assigned Labels
Upstream-assigned label bindings MUST NOT be used unless it is known
that the downstream LSR supports them. How this is known is outside
the scope of this document.
MPLS upstream label assignment requires a label distribution protocol
to distribute the binding from the upstream LSR to the downstream
LSR. Considerations that pertain to a label distribution protocol
that are described in [RFC3031] apply.
The distribution of the upstream-assigned labels is similar to either
the ordered LSP control or independent LSP control of the downstream-
assigned labels. In the former case a LSR distributes an upstream-
assigned label binding for a FEC F if it is either (a) the ingress
LSR for FEC F, or (b) if it has already received an upstream label
Raggarwa, Rekhter & Rosen [Page 5]
Internet Draft draft-raggarwa-mpls-upstream-label-01.txt October 2005
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
upstream adjacent LSR. In the latter case each LSR, upon noting that
it recognizes a particular FEC, makes an independent decision to bind
an upstream-assigned label to that FEC and to distribute that binding
to its label distribution peers.
7. Upstream Neighbor Label Space and Tunnel Label Space
If the top label of an MPLS packet is upstream assigned, when the
packet is received by LSR Rd the label is looked up in a
context-specific label space, not in a per-platform label space.
Rd uses a context-specific label space that it maintains for Ru to
"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
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
label of which is upstream assigned by Ru.
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-
text" of this packet. How this determination is made depends on 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
Rd by encapsulating it directly in a data link frame or by transmit-
ting 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 deter-
mined 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 neigh-
bor 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 tun-
nel, 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
used for transmitting either downstream assigned MPLS packets or
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
used by Ru for transmitting MPLS packets with upstream assigned MPLS
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
Raggarwa, Rekhter & Rosen [Page 6]
Internet Draft draft-raggarwa-mpls-upstream-label-01.txt October 2005
such a tunnel, it determines the "context" of this packet based on
the tunnel that the packet is received on.
Rd may maintain a separate "Tunnel Label Space" for the tunnel or it
may maintain an Upstream Neighbor Label Space" for all tunnels that
have the same root. If Rd uses the "Upstream Neighbor Label Space"
for upstream assigned MPLS packets transmitted by Ru to Rd, over IP
or MPLS tunnels, then Rd MUST be able to determine the root of these
IP/MPLS tunnels. Rd would then use a separate label space for each
unique root.
If the tunnel on which Rd receives MPLS packets with a top label L is
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.
Note that one or more of these labels may also be upstream assigned
labels.
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
[MPLS-MCAST-ENCAPS] and b) The context for L, from the source address
in the IP header.
8. Usage of Upstream Assigned Labels
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
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
<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
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
the context of Ru and forward it appropriately. This implies that
<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
for determining this are specific to the application that is using
upstream assigned labels and is outside the scope of this document.
Raggarwa, Rekhter & Rosen [Page 7]
Internet Draft draft-raggarwa-mpls-upstream-label-01.txt October 2005
9. References
9.1. Normative References
[RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon,
RFC 3031.
[RFC2119] "Key words for use in RFCs to Indicate Requirement Lev-
els.", Bradner, March 1997
[MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter,
draft-rosen-mpls-codepoint-00.txt
9.2. Informative References
[MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs"
10. Author Information
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Yakov Rekhter
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: yakov@juniper.net
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
Email: erosen@cisco.com
Raggarwa, Rekhter & Rosen [Page 8]
Internet Draft draft-raggarwa-mpls-upstream-label-01.txt October 2005
11. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assur-
ances of licenses to be made available, or the result of an attempt
made to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification can
be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
12. Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Raggarwa, Rekhter & Rosen [Page 9]
