[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-raggarwa-mpls-upstream-label) 00 01 02 03 04 05 06 07 RFC 5331

Network Working Group                                        R. Aggarwal
Internet Draft                                          Juniper Networks
Expiration Date: September 2007
                                                              Y. Rekhter
                                                        Juniper Networks

                                                                E. Rosen
                                                     Cisco Systems, Inc.

                                                              March 2007


    MPLS Upstream Label Assignment and Context Specific Label Space


                 draft-ietf-mpls-upstream-label-02.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-ietf-mpls-upstream-label-02.txt       March 2007


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          Context Label on LANs  .................................   7
 9          Usage of Upstream Assigned Labels  .....................   8
10          Acknowledgements  ......................................   8
11          References  ............................................   9
11.1        Normative References  ..................................   9
11.2        Informative References  ................................   9
12          Author Information  ....................................   9
13          Intellectual Property Statement  .......................  10
14          Full Copyright Statement  ..............................  10






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



Raggarwa, Rekhter & Rosen                                       [Page 2]


Internet Draft    draft-ietf-mpls-upstream-label-02.txt       March 2007


   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
   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



Raggarwa, Rekhter & Rosen                                       [Page 3]


Internet Draft    draft-ietf-mpls-upstream-label-02.txt       March 2007


   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
   context is the neighbor from which MPLS packets on LSP1 may be
   received 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 section 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
   "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have
   agreed to bind Label L to a Forwarding Equivalence Class (FEC), F,
   for packets 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
   distributes 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
   downstream assigned label bindings for FEC F, while other LSRs
   distribute upstream assigned label bindings. It is possible for a LSR
   to distribute 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-ietf-mpls-upstream-label-02.txt       March 2007


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
   identifier 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
   outgoing 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-ietf-mpls-upstream-label-02.txt       March 2007


   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 a MPLS packet being processed by LSR Rd is
   upstream assigned, 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 a MPLS label which is upstream
   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
   of a MPLS packet being processed is upstream assigned and if yes, the
   "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
   upstream assigned top label L, to Rd.

   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
   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
   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.



Raggarwa, Rekhter & Rosen                                       [Page 6]


Internet Draft    draft-ietf-mpls-upstream-label-02.txt       March 2007


   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.

   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



Raggarwa, Rekhter & Rosen                                       [Page 7]


Internet Draft    draft-ietf-mpls-upstream-label-02.txt       March 2007


   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
   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.


10. Acknowledgements

   Thanks to IJsbrand Wijnands's contribution, specifically for the text
   on which section 8 is based.








Raggarwa, Rekhter & Rosen                                       [Page 8]


Internet Draft    draft-ietf-mpls-upstream-label-02.txt       March 2007


11. References

11.1. Normative References

   [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon,
   RFC 3031.

   [RFC2119] "Key words for use in RFCs to Indicate Requirement
   Levels.", Bradner, March 1997

   [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter,
   draft-ietf-mpls-codepoint-01.txt


11.2. Informative References

   [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs",
   draft-ietf-l3vn-2547bis-mcast-02.txt


12. 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 9]


Internet Draft    draft-ietf-mpls-upstream-label-02.txt       March 2007


13. 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
   assurances 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.



14. Full Copyright Statement

   Copyright (C) The IETF Trust (2007).  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, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.












Raggarwa, Rekhter & Rosen                                      [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/