PCE Working Group                                                H. Chen
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                         January 8, 2017
Expires: July 12, 2017


                             Native PCE TED
                       draft-chen-pce-pcc-ted-01

Abstract

   This document presents extensions to the Path Computation Element
   Communication Protocol (PCEP) for a PCC to advertise the information
   about the links and for a PCE to build a TED based on the information
   received.

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 July 12, 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
   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.




Chen                      Expires July 12, 2017                 [Page 1]


Internet-Draft                   PCE-TED                    January 2017


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
   4.  Information on Link  . . . . . . . . . . . . . . . . . . . . .  3
   5.  Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . .  4
     5.1.  Extension to Existing Message  . . . . . . . . . . . . . .  4
       5.1.1.  TLVs . . . . . . . . . . . . . . . . . . . . . . . . .  5
       5.1.2.  Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Procedures . . . . . . . . . . . . . . . . . . . . . . . .  7
       5.2.1.  PCC Procedures . . . . . . . . . . . . . . . . . . . .  7
       5.2.2.  PCE Procedures . . . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  New Message . . . . . . . . . . . . . . . . . . . . . 10
     A.1.  LINK Object  . . . . . . . . . . . . . . . . . . . . . . . 10
     A.2.  TLVs in LINK Object  . . . . . . . . . . . . . . . . . . . 11





























Chen                      Expires July 12, 2017                 [Page 2]


Internet-Draft                   PCE-TED                    January 2017


1.  Introduction

   A PCE architecture is described in RFC 4655, in which the TED for a
   PCE is constructed through using routing protocol such as OSPF or
   IS-IS running in the domain for which the PCE is resposible.

   For a domain without running OSPF or IS-IS, the PCE responsible for
   the domain may obtain the inforamtion about the links from each of
   the PCCs running on a node in the domain.

   This document presents extensions to the Path Computation Element
   Communication Protocol (PCEP) for a PCC to advertise the information
   about the links attached to the node running the PCC and for a PCE to
   build a TED based on the information received from the PCC.

2.  Terminology

   The following terminology is used in this document.

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

   ASBR:  Autonomous System Border Router.  Router used to connect
      together ASes of the same or different service providers via one
      or more inter-AS links.

   TED:  Traffic Engineering Database.

   This document uses terminology 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.  Information on Link

   Since there is no IGP running over any link, we may not obtain the
   information about the link generated by an OSPF or IS-IS.  We may
   suppose that IP addresses are configured on links.

   For a point-to-point link connecting two nodes A and B, from A's
   point of view, the following information about the link may be
   obtained:






Chen                      Expires July 12, 2017                 [Page 3]


Internet-Draft                   PCE-TED                    January 2017


     1)  Link Type: Point-to-point
     2)  Local IP address of the link
     3)  Remote IP address of the link
     4)  Traffic engineering metric of the link
     5)  Maximum bandwidth of the link
     6)  Maximum reservable bandwidth of the link
     7)  Unreserved bandwidth of the link
     8)  Administrative group of the link


   Note that no link ID (i.e., the Router ID of the neighbor) may be
   obtained since no IGP adjacency over the link is formed.

   For a broadcast link connecting multiple nodes, on each of the nodes
   X, the same information about the link as above may be obtained
   except for the followings:

     a)  Link Type: Multi-access,
     b)  Local IP address with mask length, and
     c)  No Remote IP address.


   In other words, the information about the broadcast link obtained by
   node X comprises a), b), 4), 5), 6), 7) and 8), but does not include
   any remote IP address or link ID.  Note that no link ID (i.e., the
   interface address of the designated router for the link) may be
   obtained since no IGP selects it.

   A PCE constructs a TED for the domain for which the PCE is
   responsible after receiving the information about each of the links
   described above from the PCC running on every node in the domain plus
   the node ID such as A's ID.

5.  Extensions to PCEP

   This section describes the extensions to PCEP to distribute the
   information about links.

5.1.  Extension to Existing Message

   An existing Notification message may be extended to advertise the
   information about links.  Alternatively, a new message can be used
   (refer to Appendix A).

   The following new Notification-type (NT) and Notification-value (NV)
   of a NOTIFICATION object in a Notification message are defined:





Chen                      Expires July 12, 2017                 [Page 4]


Internet-Draft                   PCE-TED                    January 2017


   o  NT=8 (TBD): Links

      *  NV=1: Updates on Links.  A NT=8 and NV=1 indicates that the PCC
         sends the PCE updates on the information about Links, and TLVs
         containing the information are in the NOTIFICATION object.  The
         format and contents of the TLVs are described below.

      *  NV=2: Withdraw Links.  A NT=8 and NV=2 indicates that the PCC
         asks the PCE to remove Links indicated by the TLVs in the
         object.

5.1.1.  TLVs

   Two TLVs are defined for the information on links.  They are link TLV
   and Router-ID TLV.

   The format of the link TLV is illustrated below.  The Type=tTBD1
   indicates a link TLV Type.  The Length indicates the size of the Link
   Sub-TLVs.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type (tTBD1)          |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Link Sub-TLVs                         |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   A link TLV describes a single link.  It comprises a number of link
   sub-TLVs for the information described in section 4, which are the
   sub-TLVs defined in RFC 3630 or their equivalents except for the
   local IP address with mask length defined below.

   The format of the Router-ID TLV is shown below.  The Type=tTBD2
   indicates a Router-ID TLV Type.  The Length indicates the size of the
   ID and flags field.













Chen                      Expires July 12, 2017                 [Page 5]


Internet-Draft                   PCE-TED                    January 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type (tTBD2)          |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |B|E|I|      Flags              |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
     |                          32-bit/48-bit ID                     ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Flag B:     Set to 1 indicating ABR (B is for Border)
     Flag E:     Set to 1 indicating ASBR (E is for External)
     Flag I:     Set to 1 indicating ID of local router (I is for ID)


   Undefined flags MUST be set to zero.  The ID indicates the ID of a
   router.  For a router not running OSPF or IS-IS, the ID may be the
   32-bit or 48-bit ID of the router configured.

5.1.2.  Sub-TLVs

   The format of the Sub-TLV for a local IPv4 address with mask length
   is shown as follows.  The Type=stTBD1 indicates a local IPv4 Address
   with mask length.  The Length indicates the size of the IPv4 address
   and Mask Length.  The IPv4 Address indicates the local IPv4 address
   of a link.  The Mask Length indicates the length of the IPv4 address
   mask.

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type (stTBD1)         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          IPv4 Address                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mask Length  |
     +-+-+-+-+-+-+-+-+


   The format of the Sub-TLV for a local IPv6 address with mask length
   is illustrated below.  The Type=stTBD2 indicates a local IPv6 Address
   with mask length.  The Length indicates the size of the IPv6 address
   and Mask Length.  The IPv6 Address indicates the local IPv6 address
   of a link.  The Mask Length indicates the length of the IPv6 address
   mask.







Chen                      Expires July 12, 2017                 [Page 6]


Internet-Draft                   PCE-TED                    January 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type (stTBD2)         |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        IPv6 Address (16 bytes)                |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Mask Length  |
     +-+-+-+-+-+-+-+-+


5.2.  Procedures

5.2.1.  PCC Procedures

   1.  New or Changed Links

   After the session between a PCC and a PCE is established, the PCC
   sends the PCE a message containing the information about the links
   attached to the node running the PCC.

   When there are changes on the links, the PCC sends the PCE a message
   for the changed links.

   For any new or changed links, the PCC sends the PCE a message
   containing the information about these links with indication of
   Updates on Links.

   For example, for a new point-to-point link from node A to node B, the
   PCC running on node A may send the PCE a Notification message having
   a NOTIFICATION object with NT=8 and NV=1 (indicating Updates on
   Links), which contains a Router-ID TLV, followed by a link TLV.  The
   Router-ID TLV comprises the ID of node A and flag I set to 1.  The
   link TLV comprises the Sub-TLVs for the information on 1) to 8)
   described in section 4.

   For multiple new or changed links from node A, the PCC running on A
   may send the PCE a Notification message having a NOTIFICATION object
   with NT=8 and NV=1, which contains a Router-ID TLV for the ID of node
   A, followed by multiple link TLVs for the links from node A. Thus
   this one message contains the information about multiple links.

   2.  Links Down

   For any links down, the PCC sends the PCE a message containing the
   information about these links with indication of Withdraw Links.




Chen                      Expires July 12, 2017                 [Page 7]


Internet-Draft                   PCE-TED                    January 2017


   For example, for the point-to-point link from node A to node B down,
   the PCC running on node A may send the PCE a Notification message
   having a NOTIFICATION object with NT=8 and NV=2 (indicating Withdraw
   Links), which contains a Router-ID TLV, followed by a link TLV.  The
   Router-ID TLV comprises the ID of node A and flag I set to 1.  The
   link TLV comprises the Sub-TLVs for the information on 1), 2) and 3)
   described in section 4.

   For multiple links from node A down, the PCC running on node A may
   send the PCE a Notification message having a NOTIFICATION object with
   NT=8 and NV=2, which contains a Router-ID TLV for the ID of node A,
   followed by multiple link TLVs for the links from node A. The TLV for
   a point-to-point link comprises the Sub-TLVs for the information on
   1), 2) and 3) described in section 4.  The TLV for a broadcast link
   comprises the Sub-TLVs for the information on a) and b) described in
   section 4.

   3.  Simplified Message

   Alternatively, the messages may be simplified and the PCC procedures
   may change accordingly.

   For each node, the source IP address of the PCC running on the node
   may be used as the ID of the node.  The PCE knows the address after
   the session between the PCE and the PCC is up.  When the session
   between the PCE and the PCC is established, the PCC may send the PCE
   an ID of the node configured.  Thus, a message containing the
   information about links does not need include any router-ID TLV.

   For example, for a new point-to-point link attached to node A, the
   PCC running on node A sends the PCE a Notification message having a
   NOTIFICATION object with NT=8 and NV=1 (indicating Updates on Links),
   which contains a link TLV comprising the Sub-TLVs for the information
   on 1) to 8) described in section 4.  The object does not contain any
   Router-ID TLV for node A.

   In another example, for multiple links attached to node A down, the
   PCC running on node A sends the PCE a Notification message having a
   NOTIFICATION object with NT=8 and NV=2 (indicating Withdraw Links),
   which contains multiple link TLVs for the links, but does not contain
   any Router-ID TLV for node A. The TLV for a point-to-point link
   comprises the Sub-TLVs for the information on 1), 2) and 3) described
   in section 4.  The TLV for a broadcast link comprises the Sub-TLVs
   for the information on a) and b) described in section 4.







Chen                      Expires July 12, 2017                 [Page 8]


Internet-Draft                   PCE-TED                    January 2017


5.2.2.  PCE Procedures

   A PCE stores the links for each node according to the messages for
   the links received from the PCC running on the node.  For a message
   containing updates on links, it updates the links accordingly.  For a
   message containing withdraw links, it removes the links.

   When a node is down, the PCE removes the links attached to the node.

   After receiving the messages for links from the PCCs, the PCE builds
   and maintains a TED for the PCE's domain.

6.  Security Considerations

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

7.  IANA Considerations

   This section specifies requests for IANA allocation.

8.  Acknowledgement

   The authors would like to thank Eric Wu and others 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>.

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

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

   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
              (TE) Extensions to OSPF Version 2", RFC 3630,
              DOI 10.17487/RFC3630, September 2003,



Chen                      Expires July 12, 2017                 [Page 9]


Internet-Draft                   PCE-TED                    January 2017


              <http://www.rfc-editor.org/info/rfc3630>.

9.2.  Informative References

   [RFC7752]  Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
              S. Ray, "North-Bound Distribution of Link-State and
              Traffic Engineering (TE) Information Using BGP", RFC 7752,
              DOI 10.17487/RFC7752, March 2016,
              <http://www.rfc-editor.org/info/rfc7752>.

Appendix A.  New Message

   A new message may be defined to advertise the information on links.
   The format of the message containing the inforamtion on Links (IL for
   short) is as follows:

     <IL Message> ::= <Common Header>
                      <NRP>
                      <Link-List>
     where:
       <Link-List> ::= <LINK> [<Link-List>]


   Where the value of the Message-Type in the Common Header indicates
   the new message type.  The exact value is to be assigned by IANA.  A
   new RP (NRP) object will be defined, which follows the Common Header.

   A new flag W (Withdraw) in the NRP object is defined to indicate
   whether the links are withdrawn.  When flag W is set to one, the PCE
   removes the links contained in the message after receiving it from
   the PCC.  When flag W is set to zero, the PCE adds/updates the links
   in the message.

   An alternative to flag W in the NRP object is a similar flag in each
   LINK object such as using one bit in Res flags for flag W. For
   example, when the flag is set to one in the object, the PCE removes
   the links in the object after receiving it.  When the flag is set to
   zero in the object, the PCE adds/updates the links in the object.

   In another option, one byte in a LINK Object is defined as flags
   field and one bit is used as flag W. The other undefined bits in the
   flags field MUST be set to zero.

A.1.  LINK Object

   A new object, called LINK Object is defined.  The format of LINK
   object body is as follows:




Chen                      Expires July 12, 2017                [Page 10]


Internet-Draft                   PCE-TED                    January 2017


        Object-Class = ocTBD1 (LINK)
        Object-Type = 1 (Link)
      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |W|    Flags    |             Router-ID TLV                     |
     +-+-+-+-+-+-+-+-+                                               +
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Link TLVs                          |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The Router-ID TLV indicates a node in the domain, which is a local
   end of links.  Each of the Link TLVs describes a link and comprises a
   number of link Sub-TLVs.  Flag W=1 indicates withdraw the links.  W=0
   indicates new or changed links.

A.2.  TLVs in LINK Object

   The format of the Router-ID TLV 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type (tTBD1)          |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          32-bit/48-bit ID                     ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The format of the link TLV is shown 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |         Type (tTBD2)          |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Link Sub-TLVs                         |
     ~                                                               ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The link sub-TLVs are for the information on a link described in
   section 4, which are the sub-TLVs defined in RFC 3630 or their
   equivalents except for local IP address with mask length.




Chen                      Expires July 12, 2017                [Page 11]


Internet-Draft                   PCE-TED                    January 2017


Author's Address

   Huaimo Chen
   Huawei Technologies
   Boston, MA,
   USA

   EMail: Huaimo.chen@huawei.com











































Chen                      Expires July 12, 2017                [Page 12]