Skip to main content

Extensions to PCEP for Distributing Label Cross Domains
draft-chen-pce-label-x-domains-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Huaimo Chen , Autumn Liu , Fengman Xu , Mehmet Toy , Vic Liu
Last updated 2017-05-04 (Latest revision 2016-10-31)
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-chen-pce-label-x-domains-06
Internet Engineering Task Force                                  H. Chen
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                                  A. Liu
Expires: November 5, 2017                                          Ciena
                                                                   F. Xu
                                                                  M. Toy
                                                                 Verizon
                                                                  V. Liu
                                                             May 4, 2017

        Extensions to PCEP for Distributing Label Cross Domains
                 draft-chen-pce-label-x-domains-06.txt

Abstract

   This document specifies extensions to PCEP for distributing labels
   crossing domains for an inter-domain Point-to-Point (P2P) or Point-
   to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path
   (LSP).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on November 5, 2017.

Copyright Notice

   Copyright (c) 2017 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

Chen, et al.            Expires November 5, 2017                [Page 1]
Internet-Draft             Label Cross Domains                  May 2017

   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.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Conventions Used in This Document  . . . . . . . . . . . . . .  4
   4.  Label Distribution . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  An Exmaple . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . .  5
     5.1.  RP Object Extension  . . . . . . . . . . . . . . . . . . .  5
     5.2.  Label Object . . . . . . . . . . . . . . . . . . . . . . .  6
     5.3.  LSP Tunnel Object  . . . . . . . . . . . . . . . . . . . .  7
     5.4.  Request Message Extension  . . . . . . . . . . . . . . . .  9
     5.5.  Reply Message Extension  . . . . . . . . . . . . . . . . .  9
   6.  Security  Considerations . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Request Parameter Bit Flags  . . . . . . . . . . . . . . . 10
   8.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11

Chen, et al.            Expires November 5, 2017                [Page 2]
Internet-Draft             Label Cross Domains                  May 2017

1.  Introduction

   After a path crossing multiple domains is computed, an inter-domain
   Traffic Engineering (TE) Label Switched Path (LSP) tunnel may be set
   up along the path by a number of tunnel central controllers (TCCs).
   Each of the domains through which the path goes may be controlled by
   a tunnel central controller (TCC), which sets up the segment of the
   TE LSP tunnel in the domain.  When the TCC sets up the segment of the
   TE LSP tunnel in its domain that is not a domain containing the tail
   end of the tunnel, it needs a label and an interface from a
   downstream domain, which is next to it along the path.

   This document specifies extensions to PCEP for distributing a label
   and an interface from a domain to its upstream domain along the path
   for the TE LSP tunnel crossing multiple domains.

2.  Terminology

   ABR: Area Border Router.  Routers used to connect two IGP areas
   (areas in OSPF or levels in IS-IS).

   ASBR: Autonomous System Border Router.  Routers used to connect
   together ASes via inter-AS links.

   Boundary Node (BN): a boundary node is either an ABR in the context
   of inter-area Traffic Engineering or an ASBR in the context of
   inter-AS Traffic Engineering.

   Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along
   a determined sequence of domains.

   Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along
   a determined sequence of domains.

   Inter-area TE LSP: A TE LSP that crosses an IGP area boundary.

   Inter-AS TE LSP: A TE LSP that crosses an AS boundary.

   LSP: Label Switched Path.

   LSR: Label Switching Router.

   PCC: Path Computation Client.  Any client application requesting a
   path computation to be performed by a Path Computation Element.

   PCE: Path Computation Element.  An entity (component, application, or
   network node) that is capable of computing a network path or route

Chen, et al.            Expires November 5, 2017                [Page 3]
Internet-Draft             Label Cross Domains                  May 2017

   based on a network graph and applying computational constraints.

   PCE(i) is a PCE with the scope of domain(i).

   TED: Traffic Engineering Database.

   This document uses terminologies defined in RFC5440.

3.  Conventions Used in This Document

   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.

4.  Label Distribution

   The Label Distribution may be provided by the PCE-based path
   computation.  A PCE responsible for a domain computes a path segment
   for the domain, which is from an entry boundary to an exit boundary
   (or an egress) node of the domain.  The PCE gets an label from the
   entry boundary node and adds an label object containing the label and
   an interface as the incoming interface of the label in the reply
   message to be sent to the requesting PCC (or another PCE).

   When a PCE or PCC receives a reply message containing an label
   object, it removes the object from the message.  The PCE may store
   the information in the label object or send the information to
   another component such as a Tunnel Central Controller (TCC).

4.1.  An Exmaple

   Figure 1 below illustrates a simple two-AS topology.  There is a PCE
   responsible for the path computation in each AS.  A path computation
   is requested from the Tunnel Central Controller (TCC), acting as the
   PCC, which sends the path computation request to PCE-1.

   PCE-1 is unable to compute an end-to-end path and invokes PCE-2
   (possibly using the techniques described in [RFC5441]).  PCE-2
   computes a path segment from entry boundary node ASBR-2 of the right
   domain to the egress as {ASBR-2, C, D, Egress}.

   In addition to placing this path segment in the reply message to
   PCE-1, PCE-2 gets an label from the entry boundary node ASBR-2 and
   adds an label object containing the label with the interface between
   ASBR-1 and ASBR-2 into the reply message.

Chen, et al.            Expires November 5, 2017                [Page 4]
Internet-Draft             Label Cross Domains                  May 2017

    -------------------------------    ------------------------------
   |             -------           |  |    -------                   |
   |        +-->| PCE-1 |<---------+--+-->| PCE-2 |                  |
   |        |    -------           |  |    -------                   |
   |        v                      |  |    ^                         |
   |      -----                    |  |    |                         |
   |     | TCC |                   |  |    |                         |
   |     | PCC |                   |  |    |                         |
   |      -----                    |  |    v                         |
   |  -------    -    -    ------  |  |  ------    -    -    ------  |
   | |Ingress|--|A|--|B|--|ASBR-1|-+--+-|ASBR-2|--|C|--|D|--|Egress| |
   |  -------    -    -    ------  |  |  ------    -    -    ------  |
   |                               |  |                              |
    -------------------------------  ------------------------------

                  Figure 1: Example of Label Distribution

   When PCE-1 receives the reply message containing the label object
   from PCE-2, it removes the object from the message.  PCE-1 may store
   the information in the label object or send the information to
   another component such as a Tunnel Central Controller (TCC).  TCC may
   set up the segment of the LSP tunnel from Ingress to ASBR-2 using the
   label with the interface in the label object from ASBR-2.

5.  Extensions to PCEP

   This section describes the extensions to PCEP for distributing labels
   crossing domains for an inter-domain Point-to-Point (P2P) or Point-
   to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path
   (LSP).  The extensions include the definition of a new flag in the RP
   object, tunnel information and label in a PCReq/PCRep message.

5.1.  RP Object Extension

   The following flags are added into the RP Object:

       o L (Label distribution bit - 1 bit):
           0: This indicates that this is not a PCReq/PCRep message
              for distributing labels crossing domains.
           1: This indicates that this is a PCReq or PCRep message
              for distributing labels crossing domains.

Chen, et al.            Expires November 5, 2017                [Page 5]
Internet-Draft             Label Cross Domains                  May 2017

       o C (LSP tunnel Creation bit - 1 bit):
           0: This indicates that this is not a PCReq/PCRep message for
              creating the segment of the LSP tunnel.
           1: This indicates that this is a PCReq/PCRep message for
              creating the segment of the LSP tunnel in the domain
              and distributing labels to its previous domain.

   An L bit is added in the flag bits field of the RP object to tell a
   receiver of a PCReq/PCRep message that the message is for
   distributing labels crossing domains for an inter-domain LSP.  The
   IANA request is referenced in Section below (Request Parameter Bit
   Flags) of this document.

   The C bit is added in the flag bits field of the RP object to tell
   the receiver of a PCReq/PCRep message that the message is for
   creating the segment of the LSP tunnel in a domain and distributing
   labels from this domain to its previous domain.  The IANA request is
   referenced in Section below (Request Parameter Bit Flags) of this
   document.

   This L bit with the N bit defined in RFC6006 can indicate whether the
   PCReq/PCRep message is for distributing labels for an MPLS TE P2P LSP
   or an MPLS TE P2MP LSP.

    o L = 1 and N = 0: This indicates that this is a PCReq/PCRep message
                       for distributing labels for a P2P LSP.
    o L = 1 and N = 1: This indicates that this is a PCReq/PCRep message
                       for distributing labels for a P2MP LSP.

5.2.  Label Object

   The format of a label object body (Object-Type=2) is illustrated
   below, which comprises a label and an optional node sub object.  The
   node sub object contains a boundary node IP address, from which the
   label is allocated and distributed.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              Label                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Node IPv4/IPv6 sub object (optional)            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chen, et al.            Expires November 5, 2017                [Page 6]
Internet-Draft             Label Cross Domains                  May 2017

   The format of the node IPv4 address sub object (Type=1) is as
   follows:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|   Type(1)   |   Length (8)  |     Node IPv4 address         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Node IPv4 address (cont)    |        Reserved               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The format of the node IPv6 address sub object (Type=2) is
   illustrated below:

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |L|   Type(2)   |  Length (20)  |     Node IPv6 address         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                  Node IPv6 address (cont)                     |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Node IPv6 address (cont)    |        Reserved               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  LSP Tunnel Object

   The LSP tunnel object contains the information that may be used to
   identify an LSP tunnel.  An LSP tunnel may be a P2P or P2MP LSP
   tunnel.  It may be an IPv4 or IPv6 LPS tunnel.  Thus there are four
   types of LSP tunnels: 1) P2P LSP IPv4 tunnel, 2) P2P LSP IPv6 tunnel,
   3) P2MP LSP IPv4 tunnel, and 4) P2MP LSP IPv6 tunnel.

   The format of the P2P LSP IPv4/6 tunnel object body is as follows:

Chen, et al.            Expires November 5, 2017                [Page 7]
Internet-Draft             Label Cross Domains                  May 2017

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       P2P LSP Tunnel Egress IPv4/6 Address (4/16 bytes)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reserved              |            Tunnel ID          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               Extended Tunnel ID (4/16 bytes)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Reserved              |              LSP ID           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Controller ID (4/16 bytes)                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  o P2P LSP Tunnel Egress IPv4/6 Address:
      IPv4/6 address of the egress of the tunnel.
  o Tunnel ID:
      A 16-bit identifier that is constant over the life of the tunnel.
  o Extended Tunnel ID:
      A 4/16-byte identifier that is constant over the life of the tunnel.
  o LSP ID:
      A 16-bit identifier to allow resources sharing.
  o Controller ID:
      A 4/16-byte identifier for the controller responsible for the head
      segment of the tunnel.

   The format of the P2MP LSP IPv4/6 tunnel object body is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           P2MP ID                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved              |            Tunnel ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Extended Tunnel ID (4/16 bytes)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved              |              LSP ID           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Controller ID (4/16 bytes)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Chen, et al.            Expires November 5, 2017                [Page 8]
Internet-Draft             Label Cross Domains                  May 2017

  o P2MP ID:
      A 32-bit number unique within the ingress of LSP tunnel.
  o Tunnel ID:
      A 16-bit identifier that is constant over the life of the tunnel.
  o Extended Tunnel ID:
      A 4/16-byte identifier that is constant over the life of the tunnel.
  o LSP ID:
      A 16-bit identifier to allow resources sharing.
  o Controller ID:
      A 16-byte identifier for the controller responsible for the head
      segment of the tunnel.

5.4.  Request Message Extension

   Figure below illustrates the format of a request message with a
   optional LSP tunnel object:

           <PCReq Message>::= <Common Header>
                              [<svec-list>]
                              <request-list>
           <request-list>::=<request>[<request-list>]
           <request>::= <RP> <END-POINTS> [<OF>] [<LSPA>] [<BANDWIDTH>]
                        [<metric-list>] [<RRO>[<BANDWIDTH>]] [<IRO>]
                        [<LOAD-BALANCING>]
                        [<LSP-tunnel>]

5.5.  Reply Message Extension

   Below is the format of a reply message with an optional Label object:

           <PCReq Message>::= <Common Header>
                              <response-list>
           <response-list>::=<response>[<response-list>]
           <response>::= <RP>
                         [<NO-PATH>]
                         [<attribute-list>]
                         [<path-list>]
           <path-list>::=<path>[<path-list>]
           <path>::= <ERO><attribute-list>[<LSP-tunnel>][<Label>]

6.  Security  Considerations

   The mechanism described in this document does not raise any new
   security issues for the PCEP protocols.

Chen, et al.            Expires November 5, 2017                [Page 9]
Internet-Draft             Label Cross Domains                  May 2017

7.  IANA Considerations

   This section specifies requests for IANA allocation.

7.1.  Request Parameter Bit Flags

   A new RP Object Flag has been defined in this document.  IANA is
   requested to make the following allocation from the "PCEP RP Object
   Flag Field" Sub-Registry:

         Bit       Description                         Reference
          18       Label Distribution  (L-bit)         This I-D
          19       LSP tunnel Creation (C-bit)         This I-D

8.  Acknowledgement

   The author would like to thank people for their valuable comments on
   this draft.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <http://www.rfc-editor.org/info/rfc3209>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <http://www.rfc-editor.org/info/rfc5440>.

   [RFC6006]  Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T.,
              Ali, Z., and J. Meuric, "Extensions to the Path
              Computation Element Communication Protocol (PCEP) for
              Point-to-Multipoint Traffic Engineering Label Switched
              Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010,
              <http://www.rfc-editor.org/info/rfc6006>.

Chen, et al.            Expires November 5, 2017               [Page 10]
Internet-Draft             Label Cross Domains                  May 2017

9.2.  Informative References

   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
              Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/
              RFC4655, August 2006,
              <http://www.rfc-editor.org/info/rfc4655>.

   [RFC5862]  Yasukawa, S. and A. Farrel, "Path Computation Clients
              (PCC) - Path Computation Element (PCE) Requirements for
              Point-to-Multipoint MPLS-TE", RFC 5862, DOI 10.17487/
              RFC5862, June 2010,
              <http://www.rfc-editor.org/info/rfc5862>.

Authors' Addresses

   Huaimo Chen
   Huawei Technologies
   Boston, MA
   US

   Email: huaimo.chen@huawei.com

   Autumn Liu
   Ciena
   CA
   USA

   Email: hliu@ciena.com

   Fengman Xu
   Verizon
   2400 N. Glenville Dr
   Richardson, TX  75082
   USA

   Email: fengman.xu@verizon.com

   Mehmet Toy
   Verizon
   USA

   Email: mehmet.toy@verizon.com

Chen, et al.            Expires November 5, 2017               [Page 11]
Internet-Draft             Label Cross Domains                  May 2017

   Vic Liu

   Email: liu.cmri@gmail.com

Chen, et al.            Expires November 5, 2017               [Page 12]