Internet DRAFT - draft-chen-teas-rsvp-ttz

draft-chen-teas-rsvp-ttz





Internet Engineering Task Force                                  H. Chen
Internet-Draft                                                     R. Li
Intended status: Standards Track                     Huawei Technologies
Expires: December 3, 2017                                     G. Cauchie

                                                               A. Retana
                                                     Cisco Systems, Inc.
                                                                   N. So
                                                     Tata Communications
                                                                   F. Xu
                                                                  M. Toy
                                                                 Verizon
                                                                  V. Liu
                                                            China Mobile
                                                                  L. Liu
                                                                 Fijitsu
                                                            June 1, 2017


               TE LSP Crossing Topology-Transparent Zones
                    draft-chen-teas-rsvp-ttz-02.txt

Abstract

   A topology-transparent zone is virtualized as the edges of the zone
   fully connected.  This document presents the procedures for the
   establishment of Traffic Engineering (TE) LSPs crossing Topology-
   Transparent Zones.

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).  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 December 3, 2017.

Copyright Notice




Chen, et al.            Expires December 3, 2017                [Page 1]

Internet-Draft                TE LSP x TTZs                    June 2017


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
   3.  Overview of Topology-Transparent Zone (TTZ) . . . . . . . . . . 3
   4.  Set up TE LSPs crossing TTZs  . . . . . . . . . . . . . . . . . 5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



























Chen, et al.            Expires December 3, 2017                [Page 2]

Internet-Draft                TE LSP x TTZs                    June 2017


1.  Introduction

   The number of routers in a network becomes larger and larger as the
   Internet traffic keeps growing.  Through splitting the network into
   multiple areas, we can extend the network further.  However, there
   are a number of issues when a network is split further into more
   areas.

   At first, dividing a network into more areas is a very challenging
   and time consuming since it is involved in significant network
   architecture changes.

   Secondly, the services carried by the network may be interrupted
   while the network is being split into more areas.

   Furthermore, it is complex for a TE LSP crossing areas to be setup.
   In one option, a TE path crossing areas is computed by using
   collaborating PCEs [RFC5441] through PCEP[RFC5440], which is not easy
   to configure.

   Topology-transparent zone (TTZ) resolves these issues.  This document
   briefs TTZ and presents the procedures for the establishment of TE
   LSPs crossing TTZs.


2.  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 RFC 2119.


3.  Overview of Topology-Transparent Zone (TTZ)

   A Topology-Transparent Zone (TTZ) is identified by an Identifier (ID)
   called TTZ ID, and it includes a group of routers and a number of
   links connecting the routers.  A TTZ is in an IGP area.

   In addition to having the functions of an IGP area, an IGP TTZ makes
   some improvements on an IGP area, which include:

   o  An IGP TTZ is virtualized as the TTZ edge routers connected.

   o  An IGP TTZ receives the link state information about the topology
      outside of the TTZ, stores the information in the TTZ and floods
      the information through the TTZ to the routers outside of the TTZ.

   The figure below shows an area containing a TTZ: TTZ 600.



Chen, et al.            Expires December 3, 2017                [Page 3]

Internet-Draft                TE LSP x TTZs                    June 2017


                 TTZ 600
                   \
                    \ ^~^~^~^~^~^~^~^~^~^~^~^~
                     (                        )
    ===[R15]========(==[R61]------------[R63]==)======[R29]===
        ||         (   |    \          /    |   )       ||
        ||         (   |     \        /     |   )       ||
        ||         (   |      \      /      |   )       ||
        ||         (   |    ___\    /       |   )       ||
        ||         (   |   /   [R71]        |   )       ||
        ||         (   | [R73] /    \       |   )       ||
        ||         (   |      /      \      |   )       ||
        ||         (   |     /        \     |   )       ||
        ||         (   |    /          \    |   )       ||
    ===[R17]========(==[R65]------------[R67]==)======[R31]===
         \\          (//                    \\)       //
          ||         //v~v~v~v~v~v~v~v~v~v~v~\\      ||
          ||        //                        \\     ||
          ||       //                          \\    ||
           \\     //                            \\  //
       ======[R23]==============================[R25]=====
             //                                     \\
            //                                       \\


                        Figure 1: An Example of TTZ

   The area comprises routers R15, R17, R23, R25, R29 and R31.  It also
   contains TTZ 600, which comprises routers R61, R63, R65, R67, R71 and
   R73, and the links connecting them.

   There are two types of routers in a TTZ: TTZ internal routers and TTZ
   edge routers.  A TTZ internal router is a router inside the TTZ and
   its adjacent routers are in the TTZ.  A TTZ edge router is a router
   inside the TTZ and has at least one adjacent router that is outside
   of the TTZ.

   The TTZ in the figure above comprises four TTZ edge routers R61, R63,
   R65 and R67.  Each TTZ edge router is connected to at least one
   router outside of the TTZ.  For instance, router R61 is a TTZ edge
   router since it is connected to router R15, which is outside of the
   TTZ.

   In addition, the TTZ comprises two TTZ internal routers R71 and R73.
   A TTZ internal router is not connected to any router outside of the
   TTZ.  For instance, router R71 is a TTZ internal router since it is
   not connected to any router outside of the TTZ.  It is just connected
   to routers R61, R63, R65, R67 and R73 in the TTZ.



Chen, et al.            Expires December 3, 2017                [Page 4]

Internet-Draft                TE LSP x TTZs                    June 2017


   A TTZ hides the information inside the TTZ from the outside.  It does
   not directly distribute any internal information about the TTZ to a
   router outside of the TTZ.

   For instance, the TTZ in the figure above does not send the
   information about TTZ internal router R71 to any router outside of
   the TTZ in the routing domain; it does not send the information about
   the link between TTZ router R61 and R65 to any router outside of the
   TTZ.

   From a router outside of the TTZ, a TTZ is seen as a group of routers
   fully connected.  For instance, router R15 in the figure above, which
   is outside of TTZ 600, sees TTZ 600 as a group of TTZ edge routers:
   R61, R63, R65 and R67.  These four TTZ edge routers are fully
   connected.

   The cost of the "link" from one edge router to another edge router is
   the cost of the shortest path between these two routers.  The
   bandwidth of the "link" is the maximum bandwidth of a path between
   the two routers.

   In addition, a router outside of the TTZ sees TTZ edge routers having
   normal connections to the routers outside of the TTZ.  For example,
   router R15 sees four TTZ edge routers R61, R63, R65 and R67, which
   have the normal connections to R15, R29, R17 and R23, R25 and R31
   respectively.


4.  Set up TE LSPs crossing TTZs

   On a source node, we can configure a TE LSP from the source to a
   destination crossing TTZs in the same way as we configure it without
   any TTZs.  This is because the source node is not aware of any TTZs.

   For example, on node R15 in Figure 1, to set up a TE LSP from R15 to
   R31, we just configure the TE LSP by giving its source R15, its
   destination R31, and some constraints such as bandwidth as needed.

   On the source node, it computes the path to the destination based on
   the configuration of the TE LSP.  It just sees a full mess connection
   of edge nodes for every TTZ.  Thus the computation of the path is
   done in the same way as it is done without any TTZ.  After the path
   is computed, the source node starts to signal the LSP automatically
   along the path.

   For example, on node R15 in Figure 1, it computes the path to the
   destination R31.  It sees the full mess connection of four TTZ edge
   nodes R61, R63, R65 and R67 in its topology.  It computes the path in



Chen, et al.            Expires December 3, 2017                [Page 5]

Internet-Draft                TE LSP x TTZs                    June 2017


   the same way as before and may get the path: R15 - R61 - R67 - R31.
   And then it signals the TE LSP along this path.  It sends a RSVP-TE
   PATH message to R61.

   When an edge node of a TTZ receives a PATH message, it checks if the
   next hop in the ERO in the message is another edge node of the TTZ.
   If so, it computes the path segment to the other edge node and
   continues to signal the TE LSP along the path segment computed.

   For instance, when R61, which is an edge node of a TTZ, receives the
   PATH message, it computes the path segment to the other edge node R67
   (Supposed that the path segment is: R61 - R71 - R67) and continues to
   signal the TE LSP to R67 along the path segment computed.  It sends a
   PATH message to R71, which sends a PATH message to R67, which sends a
   PATH message to R31.


                   TTZ 600
                   \
                    \ ^~^~^~^~^~^~^~^~^~^~^~^~
      Source    51   (                        )
    ===[R15]========(==[R61]------------[R63]==)======[R29]===
        ||         (   |    \          /    |   )       ||
        ||         (   |     \        /     |   )       ||
        ||         (   |      \11    /      |   )       ||
        ||         (   |    ___\    /       |   )       ||
        ||         (   |   /   [R71]        |   )       ||
        ||         (   | [R73] /    \       |   )       ||
        ||         (   |      /      \      |   )       ||
        ||         (   |     /        \17   |   )       ||
        ||         (   |    /          \    |   )  71   ||
    ===[R17]========(==[R65]------------[R67]==)======[R31]===
         \\          (//                    \\)       //Destination
          ||         //v~v~v~v~v~v~v~v~v~v~v~\\      ||
          ||        //                        \\     ||
          ||       //                          \\    ||
           \\     //                            \\  //
       ======[R23]==============================[R25]=====
             //                                     \\
            //                                       \\


                       Figure 2: LSP from R15 to R31

   When R31 receives the PATH message from R67, it allocates a label
   (e.g., 71), reserves the bandwidth as needed, and sends a RESV
   message with the label (71) to R67.  It sets the forwarding entry for
   the TE LSP using label 71 as inbound label.



Chen, et al.            Expires December 3, 2017                [Page 6]

Internet-Draft                TE LSP x TTZs                    June 2017


   When R67 receives the RESV message from R31, it allocates a label
   (e.g., 17), and sends a RESV message with the label (17) to R71.  It
   also sets the cross connect for the TE LSP using labels 17 and 71 as
   inbound label and outbound label respectively.

   When R71 receives the RESV message with the label (17) from R67, it
   allocates a label (e.g., 11), and sends a RESV message with the label
   (11) to R61.  It sets the cross connect for the TE LSP using labels
   11 and 17 as inbound label and outbound label respectively.

   When R61 receives the RESV message with the label (11) from R71, it
   allocates a label (e.g., 51), and sends a RESV message with the label
   (51) to R15.  It sets the cross connect for the TE LSP using labels
   51 and 11 as inbound label and outbound label respectively.

   When R15 receives the RESV message with the label (51) from R61, it
   sets the forwarding entry for the TE LSP using label 51 as outbound
   label.  At this point, the set up of TE LSP from R15 to R31 is done.

   The source node (i.e., head-end LSR) sets the "label recording
   requested" flag in the SESSION_ATTRIBUTE object for LSPs requesting
   local protection.  This will cause all LSRs to record their INBOUND
   labels.

   For a TE LSP crossing a TTZ, we may assume that it goes into the TTZ
   through an in edge node of the TTZ and goes out of the TTZ from a out
   edge node of the TTZ.

   For example, the TE LSP crossing TTZ 600 in Figure 2 is from R15 to
   R61 to R71 to R67 to R31.  The LSP goes into TTZ 600 through the edge
   node R61, which is the in edge node.  The LSP goes out of TTZ 600
   from the edge node R67, which is the out edge node.

   On the in edge node of the TTZ for the TE LSP, it does not record all
   the INBOUND labels inside the TTZ in the RESV message to be sent to
   its previous hop node.  It just records the INBOUND label of the out
   edge node.

   For example, R61 (the in edge node of TTZ 600 for the TE LSP in
   Figure 2) just keeps the INBOUND label 17 of R67 (the out edge node).
   It does not record any other INBOUND labels inside TTZ 600.  It will
   remove the INBOUND label 11 of the TTZ internal node R71.  Thus the
   RESV message sent by R61 to its previous hop node R15 records two
   INBOUND labels 17 and 71, which are the INBOUND labels of R67 and R31
   respectively.

   On the out edge node of the TTZ for the TE LSP, it does not record
   all the hops inside the TTZ in the PATH message to its next hop node.



Chen, et al.            Expires December 3, 2017                [Page 7]

Internet-Draft                TE LSP x TTZs                    June 2017


   It just records one hop from the in edge to the out edge.


5.  Security Considerations

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


6.  IANA Considerations

   There is not any requirement for IANA to assign a code point.


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

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, DOI 10.17487/
              RFC3031, January 2001,
              <http://www.rfc-editor.org/info/rfc3031>.

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

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <http://www.rfc-editor.org/info/rfc4090>.

   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
              "A Backward-Recursive PCE-Based Computation (BRPC)
              Procedure to Compute Shortest Constrained Inter-Domain
              Traffic Engineering Label Switched Paths", RFC 5441,
              DOI 10.17487/RFC5441, April 2009,
              <http://www.rfc-editor.org/info/rfc5441>.

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




Chen, et al.            Expires December 3, 2017                [Page 8]

Internet-Draft                TE LSP x TTZs                    June 2017


Authors' Addresses

   Huaimo Chen
   Huawei Technologies
   Boston, MA
   USA

   Email: huaimo.chen@huawei.com


   Renwei Li
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA
   USA

   Email: renwei.li@huawei.com


   Gregory Cauchie
   FRANCE

   Email: greg.cauchie@gmail.com


   Alvaro Retana
   Cisco Systems, Inc.
   7025 Kit Creek Rd.
   Raleigh, NC  27709
   USA

   Email: aretana@cisco.com


   Ning So
   Tata Communications
   USA

   Email: ningso01@gmail.com












Chen, et al.            Expires December 3, 2017                [Page 9]

Internet-Draft                TE LSP x TTZs                    June 2017


   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


   Vic Liu
   China Mobile
   No.32 Xuanwumen West Street, Xicheng District
   Beijing,   100053
   China

   Email: liu.cmri@gmail.com


   Lei Liu
   Fijitsu
   USA

   Email: liulei.kddi@gmail.com





















Chen, et al.            Expires December 3, 2017               [Page 10]