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

Versions: (draft-raggarwa-mpls-rsvp-upstream) 00 01 02 03 04 05

Network Working Group                                        R. Aggarwal
Internet Draft                                          Juniper Networks
Expiration Date: September 2010
                                                           J. L. Le Roux
                                                          France Telecom

                                                          March 08, 2010


               MPLS Upstream Label Assignment for RSVP-TE


                  draft-ietf-mpls-rsvp-upstream-05.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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.

Copyright and License Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Raggarwa & LeRoux                                               [Page 1]


Internet Draft    draft-ietf-mpls-rsvp-upstream-05.txt        March 2010


   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008. The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.


Abstract

   This document describes procedures for distributing upstream-assigned
   labels for Resource Reservation Protocol - Traffic Engineering (RSVP-
   TE).  It also describes how these procedures can be used for avoiding
   branch LSR traffic replication on a LAN for RSVP-TE point-to-
   multipoint (P2MP)LSPs.



Table of Contents

 1          Specification of requirements  .........................   3
 2          Introduction  ..........................................   3
 3          RSVP-TE Upstream Label Assignment Capability  ..........   3
 4          Distributing Upstream-Assigned Labels in RSVP-TE  ......   4
 4.1        Procedures  ............................................   5
 5          RSVP-TE Tunnel Identifier Exchange  ....................   5
 6          RSVP-TE Point-to-Multipoint LSPs on a LAN  .............   7
 7          IANA Considerations  ...................................   8
 8          Security Considerations  ...............................   8
 9          Acknowledgements  ......................................   9
10          References  ............................................   9
10.1        Normative References  ..................................   9
10.2        Informative References  ................................   9
11          Author's Address  ......................................  10








Raggarwa & LeRoux                                               [Page 2]


Internet Draft    draft-ietf-mpls-rsvp-upstream-05.txt        March 2010


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

   This document describes procedures for distributing upstream-assigned
   labels [RFC5331] for Resource Reservation Protocol with Traffic
   Engineering (RSVP-TE). These procedures follow the architecture for
   MPLS Upstream Label Assignment described in [RFC5331].

   This document describes extensions to RSVP-TE that a LSR can use to
   advertise to its neighboring LSRs whether the LSR supports upstream
   label assignment.

   This document also describes extensions to RSVP-TE to distribute
   upstream-assigned labels.

   The usage of MPLS upstream label assignment using RSVP-TE for
   avoiding branch LSR [RSVP-P2MP] traffic replication on a LAN for
   RSVP-TE P2MP TE LSPs [RFC4875] is also described.


3. RSVP-TE Upstream Label Assignment Capability

   According to [RFC5331], upstream-assigned label bindings MUST NOT be
   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
   to its RSVP-TE neighbor LSR(s) its support of upstream-assigned
   labels.

   [RFC5063] defines a CAPABILITY object to be carried within Hello
   messages, and used to indicate the set of capabilities supported by a
   node. This object provides the ability to encode a set of capability
   flags.  This document defines a new flag, the U flag, to signal a
   LSR's support of upstream label assignment to its RSVP-TE neighbors.

   The format of a Capability object is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             | Class-Num(TBA)|  C-Type  (1)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Reserved                      |U|T|R|S|



Raggarwa & LeRoux                                               [Page 3]


Internet Draft    draft-ietf-mpls-rsvp-upstream-05.txt        March 2010


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   T, R and S flags are defined in [RFC5063].

   Upstream Label Assignement Capable (U): 1 bit When set this means
   that the LSR is capable of both distributing upstream-assigned label
   bindings and receiving upstream-assigned label bindings

   Reserved bits MUST be set to zero on transmission and MUST be ignored
   on receipt.

   The usage of RSVP-TE Hello messages for exchanging upstream label
   assignment capability implies that a LSR MAY exchange RSVP-TE Hellos
   with a neighbor before sending/receiving any other RSVP-TE messages
   to/from that neighbor.


4. Distributing Upstream-Assigned Labels in RSVP-TE

   An optional RSVP-TE object, the UPSTREAM_ASSIGNED_LABEL object is
   introduced to signal an upstream-assigned label. The Class-Num for
   this object comes from the 0bbbbbbb space and is to be determined by
   IANA.

   UPSTREAM_ASSIGNED_LABEL C-Num = TBD

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Reserved                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Label                                  |
      |                          ....                                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The label can be encoded as in [RFC3209] when the C-Type is 1 or as a
   Generalized Label [RFC3473] when the C-Type is 2 or 3.












Raggarwa & LeRoux                                               [Page 4]


Internet Draft    draft-ietf-mpls-rsvp-upstream-05.txt        March 2010


4.1. Procedures

   A RSVP-TE LSR that assigns Upstream-Assigned Labels, distributes them
   to the downstream LSRs by including them in RSVP-TE Path messages.

   A RSVP-TE LSR MUST NOT distribute the UPSTREAM_ASSIGNED_LABEL Object
   to a downstream LSR if the downstream LSR had not previously
   advertised the CAPABILITY object with the U bit set in its RSVP-TE
   Hello messages.

   If a downstream RSVP-TE LSR receives a Path message that carries an
   UPSTREAM_ASSIGNED_LABEL Object and the LSR does not support the
   object C-Num/C-Type it will return an "Unknown Object C-Num/C-Type"
   error. If the LSR does support the object, but is unable to process
   the upstream-assigned label as described in [RFC5331] it SHOULD send
   a PathErr with the error code "Routing problem" and the error value
   "MPLS Upstream Assigned Label Processing Failure". If the LSR
   successfully processes the Path message and the upstream-assigned
   label it MUST send a Resv message upstream as per [RFC3209] but it
   MUST NOT include the LABEL object with a downstream assigned label in
   the Resv Message. This is because as described in [RFC5331] two LSRs
   Ru and Rd 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, for packets that are to be
   transmitted on the LSP from Ru to Rd.


5. RSVP-TE Tunnel Identifier Exchange

   As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS
   packet, the top label of which (L) is upstream-assigned, to a
   downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In
   this case the fact that L is upstream-assigned is determined by Rd by
   the tunnel on which the packet is received. 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.

   When RSVP-TE is used for upstream label assignment, the IF_ID
   RSVP_HOP object is used for signaling the Tunnel Identifier. If Ru
   uses an IP or MPLS tunnel to transmit MPLS packets with upstream
   assigned labels to Rd, Ru MUST include the IF_ID RSVP_HOP object
   [RFC3473] in Path messages along with the UPSTREAM_ASSIGNED_LABEL
   Object.

   Four new TLVs are introduced in the IF_ID RSVP_HOP object [RFC3471]
   to support RSVP-TE P2MP LSPs, LDP P2MP LSPs, IP Multicast Tunnels and
   context labels. The TLV value acts as the tunnel identifier.



Raggarwa & LeRoux                                               [Page 5]


Internet Draft    draft-ietf-mpls-rsvp-upstream-05.txt        March 2010


   1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE
   P2MP Session Object and optionally the P2MP Sender Template Object
   [RFC4875].  The TLV value identifies the RSVP-TE P2MP LSP.  This
   mechanism extends RSVP-TE P2P Hierarchy [LSP-HIER] to RSVP-TE P2MP
   Hierarchy. It allows Ru to tunnel an "inner" RSVP-TE P2MP LSP, the
   label for which is upstream assigned, over an "outer" RSVP-TE P2MP
   LSP that has leaves <Rd1...Rdn>. The P2MP LSP IF_ID TLV allows Ru to
   signal to <Rd1...Rdn> the binding of the inner P2MP LSP to the outer
   P2MP LSP. The control plane signaling between Ru and <Rd1...Rdn> for
   the inner P2MP LSP uses directed RSVP-TE signaling messages as in
   [LSP-HIER].

   2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC
   as defined in [MLDP]. The TLV value identifies the LDP P2MP LSP. It
   allows Ru to tunnel an "inner" RSVP-TE P2MP LSP, the label for which
   is upstream assigned, over an "outer" LDP P2MP LSP that has leaves
   <Rd1...Rdn>. The P2MP LSP IF_ID TLV allows Ru to signal to
   <Rd1...Rdn>  the binding of the inner LDP P2MP LSP to the outer LDP-
   P2MP LSP. The control plane signaling between Ru and <Rd1...Rdn> for
   the inner P2MP LSP uses directed RSVP-TE signaling messages as in
   [LSP-HIER].

   2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is
   a <Source Address, Multicast Group Address> tuple. Source Address is
   the IP address of the root of the tunnel i.e. Ru, and Multicast Group
   Address is the Multicast Group Address used by the tunnel.

   3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is
   a <Source Address, MPLS Context Label> tuple. The Source Address
   belongs to Ru and the MPLS Context Label is an upstream assigned
   label, assigned by Ru. This allows Ru to tunnel an "inner" RSVP-TE
   P2MP LSP, the label of which is upstream assigned, over an "outer"
   MPLS LSP, where the outer LSP has the following property:

     + The label pushed by Ru for the outer MPLS LSP is an upstream
       assigned context label, assigned by Ru. When <Rd1...Rdn> perform
       a MPLS label lookup on this label a combination of this label and
       the incoming interface MUST be sufficient for <Rd1...Rdn> to
       uniquely determine Ru's context specific label space to lookup
       the next label on the stack in. <Rd1...Rdn> MUST receive the data
       sent by Ru with the context specific label assigned by Ru being
       the top label on the label stack.

   Currently the usage of the context label TLV is limited only to RSVP-
   TE P2MP LSPs on a LAN as specified in the next section. The context
   label TLV MUST NOT be used for any other purposes.

   Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP



Raggarwa & LeRoux                                               [Page 6]


Internet Draft    draft-ietf-mpls-rsvp-upstream-05.txt        March 2010


   the above procedures assume that Ru has a priori knowledge of all the
   <Rd1, ... Rdn>. In the scenario where the outer P2MP LSP is signaled
   using RSVP-TE, Ru can obtain this information from RSVP-TE. However,
   in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP
   does not provide this information to Ru. In this scenario the
   procedures by which Ru could acquire this information are outside the
   scope of this document.


6. RSVP-TE Point-to-Multipoint LSPs on a LAN

   This section describes one application of upstream label assignment
   using RSVP-TE. Further applications are to be described in separate
   documents.

   [RFC4875] describes how to setup RSVP-TE P2MP LSPs. On a LAN the
   solution described in [RFC4875] relies on "ingress replication".  A
   LSR on a LAN (say Il), that is a branch LSR for a P2MP LSP, (say Ru)
   sends a separate copy of a packet that it receives on the P2MP LSP to
   each of the downstream LSRs on the LAN (say <Rd1...Rdn> that are
   adjacent to it in the P2MP LSP.

   In order to increase efficiency of bandwidth utilization, it is
   desirable for Ru to send a single copy of the packet for the P2MP LSP
   on the LAN, when there are multiple downstream routers on the LAN
   that are adjacent in that P2MP LSP. This requires that each of
   <Rd1...Rdn> must be able to associate the label L, used by Ru to
   transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It
   is possible to achieve this using RSVP-TE upstream-assigned labels
   with the following procedures. Assume that Ru and <Rd1...Rdn> support
   upstream label assignment.

   Ru sends a Path message for the P2MP LSP to each of <Rd1...Rdn> that
   is adjacent on the P2MP LSP, with the same UPSTREAM_ASSIGNED_LABEL
   object. This object carries an upstream assigned label, L. This
   message also carries a MPLS Context Label TLV, as described in the
   previous section, with the value of the MPLS label set to a value
   assigned by Ru on inteface I1 as specified in [RFC5331]. <Rd1...Rdn>
   "reserve" the upstream assigned label in the separate Upstream
   Neighbor Label Space that they maintain for Ru [RFC5331].

   Ru can then transmit a single packet for the P2MP LSP to <Rd1..Rdn>
   with a top label L using procedures defined in [RFC5331] and
   [RFC5332]. The MPLS packet transmitted by Ru contains as the top
   label the context label assigned by Ru on the LAN interface, I1. The
   bottom label is the upstream label assigned by Ru to the RSVP-TE P2MP
   LSP. The top label is looked up in the context of the LAN interface,
   I1, [RFC5331] by a downstream LSR on the LAN. This lookup enables the



Raggarwa & LeRoux                                               [Page 7]


Internet Draft    draft-ietf-mpls-rsvp-upstream-05.txt        March 2010


   downstream LSR to determine the context specific label space to
   lookup the inner label in.

   If a subset of <Rd1...Rdn> do not support upstream label assignment
   these procedures can still be used between Ru and the remaining
   subset of <Rd1...Rdn>. Ingress replication and downstream label
   assignment will continue to be used for LSRs that do not support
   upstream label assignment.




7. IANA Considerations

   This document defines a new U flag in the CAPABILITY object defined
   by [RFC5063]. IANA is requested to assign a new bit to this flag from
   the 32 bit flags field of the CAPABILITY object.

   This document defines a new RSVP-TE object, the
   UPSTREAM_ASSIGNED_LABEL object. The Class-Num for this object comes
   from the 0bbbbbbb space and IANA is requested to assign this Class-
   Num.

   This document defines four new TLVs in the IF_ID RSVP_HOP object
   [RFC3471]:

     - RSVP-TE P2MP LSP TLV

     - LDP P2MP LSP TLV

     - IP Multicast Tunnel TLV

     -  MPLS Context Label TLV


   IANA is requested to assign the type values of these TLVs.


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



Raggarwa & LeRoux                                               [Page 8]


Internet Draft    draft-ietf-mpls-rsvp-upstream-05.txt        March 2010


9. Acknowledgements

   Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and
   Thomas Morin for their comments.


10. References

10.1. Normative References

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

   [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label
   Assignment and Context Specific Label Space", draft-ietf-mpls-
   upstream-label-05.txt

   [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, draft-ietf-
   mpls-codepoint-08.txt

   [RFC3209] Awduche et. al." "RSVP-TE: Extensions to RSVP for LSP
   Tunnels", RFC 3209, December 2001.

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

   [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label
   Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic
   Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

   [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label
   Switching (GMPLS) Signaling Functional Description", RFC 3471 January
   2003.

   [RFC5063] A. Satyanarayana et. al., "Extensions to GMPLS Resource
   Reservation Protocol (RSVP) Graceful Restart", RFC5063


10.2. Informative References

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

   [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors],
   "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875

   [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS
   Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt



Raggarwa & LeRoux                                               [Page 9]


Internet Draft    draft-ietf-mpls-rsvp-upstream-05.txt        March 2010


11. Author's Address

   Rahul Aggarwal
   Juniper Networks
   1194 North Mathilda Ave.
   Sunnyvale, CA 94089
   Phone: +1-408-936-2720
   Email: rahul@juniper.net

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex
   France
   E-mail: jeanlouis.leroux@orange-ftgroup.com




































Raggarwa & LeRoux                                              [Page 10]


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