Internet DRAFT - draft-zhangj-pce-multi-fiber-inter-domain

draft-zhangj-pce-multi-fiber-inter-domain






Network Working Group                                           J. Zhang
Internet-Draft                                                  JJ. Wang
Intended status: Informational                                  YL. Zhao
Expires: July 13, 2013                                         SG. Huang
                                                                  Y. Bai
                                                                    BUPT
                                                                ZH. Wang
                                                                 XP. Cao
                                                         ZTE Corporation
                                                         January 9, 2013


      PCEP extension for multi-fiber existing in inter-domain link
              draft-zhangj-pce-multi-fiber-inter-domain-01

Abstract

   Currently, most route computing algorithms only compute a shortest or
   an optimal path.The results of this computation just refer to link
   level, without consideration of fibers.  But, in real networks, the
   link between two adjacent nodes always has multi-fibers.  This
   condition above happens more frequently especially for the gateway
   nodes in the multi-domain network.  Moreover, the number of links
   between two adjacent domains is always more than one.  From the view
   of parent PCE, the two conditions above will be regarded as the
   problem of multi-fibers between adjacent nodes.  However, most route
   computing algorithms always can not solve the problem of multi-fiber
   between adjacent nodes.  As a result, parent PCE can not compute the
   route sequence with specific fibers.  It brings distress and problems
   when parent PCE computing the loose route sequence.

   In order to solve the problems existing in real networks, an
   efficient solution will be proposed for parent PCE facing the multi-
   fiber between adjacent nodes.  Some interface and structure will be
   expanded in this proposal.

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



Zhang, et al.             Expires July 13, 2013                 [Page 1]

Internet-Draft              multi-fiber-link                January 2013


   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 13, 2013.

Copyright Notice

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
































Zhang, et al.             Expires July 13, 2013                 [Page 2]

Internet-Draft              multi-fiber-link                January 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  PCE discovery  . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  TED of parent PCE  . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Communication of domain connection information . . . . . .  5
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  6
   3.  Terminologies  . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Procedure  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  PCEP Protocol Extension  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11



































Zhang, et al.             Expires July 13, 2013                 [Page 3]

Internet-Draft              multi-fiber-link                January 2013


1.  Introduction

   In real networks, the link between two adjacent nodes always has
   multi-fibers.  The condition above happens more frequently in the
   multi-domain network.  Moreover, the number of links between two
   adjacent domains is always more than one.  From the view of parent
   PCE, the two conditions above will be regarded as the problem of
   multi-fiber between adjacent nodes.  However, most route computing
   algorithms always can not solve the problem of multi-fiber between
   adjacent nodes.  As a result, parent PCE will not compute the route
   sequence with specific fibers.  It brings distress and problems when
   parent PCE computing the loose route sequence.

   Most route calculating situations of multi-fiber link can be solved
   by bundling scheme.  The fiber information of one link will always be
   bundled to inform other modules.  However, there are some situations
   that bundling scheme can not process.  For instance, only the total
   free bandwidth of the link and maximum free bandwidth of fibers in
   this link can be described by the bundle information.  It is assumed
   that there are 10 fibers in one link and the total free bandwidth is
   60Gb/s.  The maximum free bandwidth of fibers in this link is 10Gb/
   s.(Actually free bandwidth of other fibers is less than 10GB/s.)  For
   example, three requests arrive at the same moment to request 10Gb/s
   for bandwidth.  With the bundling information, all the three requests
   can be met.  However, only one of the requests can be allocated with
   10Gb/s and the other two will fail.  If the detail information of
   fibers in this link can be known completely, the three requests for
   10Gb/s will not be accepted at the same time and the other two
   requests will not fail.  In the situation like this, the bundling
   scheme has many shortages and the detail information of fiber need to
   be described in some other structure.

   As a result, we need to let the parent PCE know the detail
   information of every fiber in the link.  The parent PCE will compute
   out the detail route sequence with fiber information.  And it will
   recover the shortage of the bundling scheme and the existing route
   computation algorithm.

1.1.  PCE discovery

   The parent PCE also needs to know the inter-domain connectivity.
   This information could be configured with suitable policy and
   commercial rules, or could be learned from the child PCEs.

   In order to make the parent PCE know more interconnection
   information, the child PCE will report the identity of its neighbor
   domains.  The IGP in each neighbor domain can advertise its inter-
   domain TE link capabilities [RFC5316], [RFC5392].  This information



Zhang, et al.             Expires July 13, 2013                 [Page 4]

Internet-Draft              multi-fiber-link                January 2013


   can be collected by the child PCEs and forwarded to the parent PCE,
   or the parent PCE could participate in the IGP in the child domains.

1.2.  TED of parent PCE

   The parent PCE maintains a domain topology map of the child domains
   and their interconnectivity.  Where inter-domain connectivity is
   provided by TE links, the capabilities of those links may also be
   known to the parent PCE.  The parent PCE maintains a traffic
   engineering database (TED) for the parent domain in the same way that
   any PCE does.

   The mechanism for building the parent TED is likely to rely heavily
   on administrative configuration and commercial issues because the
   network was probably partitioned into domains specifically to address
   these issues.

   In practice, certain information may be passed from the child domains
   to the parent PCE to help build the parent TED.  It is much more
   likely that a suitable solution will involve specific communication
   from an entity in the child domain (such as the child PCE) to convey
   the necessary information.

1.3.  Communication of domain connection information

   The parent PCE needs a parent TED and it indicates that the
   information might be supplied from the child PCEs in each domain.
   This requires a mechanism whereby information about inter-domain
   links can be supplied by a child PCE to a parent PCE, for example on
   a PCEP Notify (PCNtf) message.

   The information that would be exchanged includes:

   o  Identifier of advertising child PCE

   o  Identifier of PCE's domain

   o  Identifier of the link

   o  TE properties of the link (metrics, bandwidth)

   o  Other properties of the link (technology-specific)

   o  Identifier of link end-points

   o  Identifier of adjacent domain

   It may be desirable for this information to be periodically updated,



Zhang, et al.             Expires July 13, 2013                 [Page 5]

Internet-Draft              multi-fiber-link                January 2013


   for example, when available bandwidth changes.  In this case, the
   parent PCE might be given the ability to configure thresholds in the
   child PCE to prevent flapping of information.


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


3.  Terminologies

   PCE (Path Computation Element): an entity (component, application or
   network node) that is capable of computing a network path or route
   based on a network graph and applying computational constraints.


4.  Procedure

   Firstly, parent PCE needs to discover the child PCEs to build the
   topology from parent PCE's eye.  This needs the child PCEs to report
   the inter-domain link information to parent PCE.  Parent PCE builds
   its TED just like the child PCE does.  The child PCEs report the
   inter-domain link information to parent PCE with the notification
   message.  When all the reported information are collected, parent PCE
   will get the topology between child PCEs.  When there are more than
   one inter-domain links between two adjacent domains or more than one
   fibers between two adjacent gateway nodes, parent PCE will get the
   topology of child PCEs with the feature of multi-fiber between
   adjacent nodes.

   Until now most route computation algorithms are not supporting the
   condition that there are multi-fiber between adjacent nodes.
   However, a solution with increasing the fake nodes can fulfill the
   task.  The introduction of the solution follows:

   The solution to solve the route computation with multi-fiber between
   adjacent nodes:

   First, we need to record the information of original topology for a
   backup.  Then, if there are n original edges between two nodes, we
   increase a fake node in each of n-1 edges except the least weight
   edge.  This will divided the original edge into two sub-segments.
   Per sub-segment will become a new edge and its weight will become the
   half value of the original edge's.  Based on the information of new
   topology just formed, we compute the route sequence between source



Zhang, et al.             Expires July 13, 2013                 [Page 6]

Internet-Draft              multi-fiber-link                January 2013


   node and destination node with the original algorithm.  The
   calculated route sequences must be checked to make sure that the new
   edge and fake node will be restored to the original edge.

   Thus, the different fibers of every link can be distinguished.
   Moreover, the original algorithm can be used to compute route
   sequences where the multi-fiber between adjacent nodes exists.  The
   problem of computing route sequences with multi-fiber between
   adjacent nodes can be solved well.

   The information of inter-domain link must be extended to the
   granularity of fiber.  Based on the computing proposal of multi-fiber
   between nodes, the parent PCE can compute out the detail inter-domain
   loose route.  The proposal can provide the solution of the
   computation of multi-fiber between adjacent nodes which can not be
   completed before.  This also can help the process of resource
   reservation.

   The proposal can solve the loose route sequences with inter-domain
   multi-fiber between adjacent gateway nodes for parent PCE well.
   However, the information of every fiber of inter-domain link must be
   collected by the parent PCE.  As a result, the structure of inter-
   domain link used to fulfill the communication between parent PCE and
   child PCE must be extended to adjust the new efficient proposal.


5.  PCEP Protocol Extension

   In hierarchy PCE protocol, NOIFICATION message is used to communicate
   with parent PCE and child PCE.  The format of NOTIFICATION 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Reserved   |      Flags    |     NT        |     NV        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                    Optional TLVs                            //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The related TLV for inter-domain information is inter-domain link
   TLV.

   IGP in each neighbor domain can advertise its inter-domain TE link
   capabilities.  This information can be collected by the child PCEs



Zhang, et al.             Expires July 13, 2013                 [Page 7]

Internet-Draft              multi-fiber-link                January 2013


   and forwarded to the parent PCE.  PCEP Inter-domain Link TLV is used
   for carrying the inter-domain TE link attributes for this purpose.
   Each Inter-domain Link TLV can carry the attributes of one inter-
   domain link at the most.

   The length of inter-domain Link TLV is variable.  The format of this
   TLV is defined 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     Advertise Router ID                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                        sub-TLVs                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Advertise Router ID (32 bits): indicates the router ID which
   advertises the TE LSA or LSP.

   Sub-TLVs: the OSPF sub-TLVs for a TE link which defined in [RFC5392]
   and other associated OSPF RFCs.  It is noted that if the IGP is IS-IS
   for the child domain the sub-TLVs must be converted to the OSPF sub-
   TLVs format when sending this information to the parent PCE through
   PCEP PCNtf message.

   A new type of sub-TLV will be extended in this document in order to
   store the fiber information of every link which includes the number
   of fiber, wavelength information, source IP, destination IP and so
   on.

   The new sub-TLV consists of a header and sub-sub-TLV set.  The header
   includes the type of this sub-TLV, the number of fiber in this link,
   the source IP of this link, the destination IP of this link.  The
   sub-sub-TLV includes the number of the fiber, the capacity of the
   fiber, the free bandwidth of the fiber, TE metric information.  The
   sub-sub-TLV set is formed by N sub-sub-TLVs.  N is the number of
   fibers in the link.

   The new sub TLV is defined below:









Zhang, et al.             Expires July 13, 2013                 [Page 8]

Internet-Draft              multi-fiber-link                January 2013


      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               |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Source IP                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                          Destination IP                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Sub-sub-TLV set                       |
     .                                                               .
     .                                                               .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type: the type value of this sub-TLV.

   Length: the length of this sub-TLV.

   Source IP: the source IP of this link.

   Destination IP: the destination IP of this link.

   Sub-sub-TLV set: the set of N sub-sub-TLVs, N means the number of
   fibers in this link.

   Sub-sub-TLV is defined 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                         Fiber number                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                            Capacity                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Unreserved Bandwidth                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Wavelength Information                  |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+









Zhang, et al.             Expires July 13, 2013                 [Page 9]

Internet-Draft              multi-fiber-link                January 2013


6.  IANA Considerations

   TBD.


7.  Security Considerations

   TBD.


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFC's to Indicate
              Requirement Levels", RFC 2119, March 1997.

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

   [RFC5440]  Vasseur, JP. and JL. Le Roux, "Traffic Engineering (TE)
              Extensions to OSPF Version 2", RFC 5440, March 2009.

   [RFC5441]  Vasseur, JP. and R. Zhang, "A Backward-Recursive PCE-Based
              Computation (BRPC) Procedure to Compute Shortest
              Constrained Inter-Domain Traffic Engineering Label
              Switched Paths", RFC 5441, April 2009.

8.2.  Informative References

   [draft-ietf-pce-brpc-09]
              Vasseur, JP. and R. Zhang, "A Backward Recursive PCE-based
              Computation (BRPC) Procedure To Compute Shortest
              Constrained Inter-domain Traffic Engineering Label
              Switched Paths", April 2008.

   [draft-ietf-pce-hierarchy-fwk-01]
              King, D., Farrel, A., and Q. Zhao, "The Application of the
              Path Computation Element Architecture to the Determination
              of a Sequence of Domains in MPLS and GMPLS", March 2012.

   [draft-zhang-pce-hierarchy-extensions-00]
              Zhang, F. and Q. Zhao, "Extensions to Path Computation
              Element Communication Protocol (PCEP) for Hierarchical
              Path Computation Elements (PCE)", April 2011.

   [draft-zhang-pce-hierarchy-extensions-01]



Zhang, et al.             Expires July 13, 2013                [Page 10]

Internet-Draft              multi-fiber-link                January 2013


              Zhang, F. and Q. Zhao, "Extensions to Path Computation
              Element Communication Protocol (PCEP) for Hierarchical
              Path Computation Elements (PCE)", October 2011.


Authors' Addresses

   Jie Zhang
   BUPT
   No.10,Xitucheng Road,Haidian District
   Beijing  100876
   P.R.China

   Phone: +8613911060930
   Email: lgr24@bupt.edu.cn
   URI:   http://www.bupt.edu.cn/


   Jingjing Wang
   BUPT
   No.10,Xitucheng Road,Haidian District
   Beijing  100876
   P.R.China

   Phone: +8615901047466
   Email: buptwjj@yahoo.cn
   URI:   http://www.bupt.edu.cn/


   Yongli Zhao
   BUPT
   No.10,Xitucheng Road,Haidian District
   Beijing  100876
   P.R.China

   Phone: +8613811761857
   Email: yonglizhao@bupt.edu.cn
   URI:   http://www.bupt.edu.cn/













Zhang, et al.             Expires July 13, 2013                [Page 11]

Internet-Draft              multi-fiber-link                January 2013


   Shanguo Huang
   BUPT
   No.10,Xitucheng Road,Haidian District
   Beijing  100876
   P.R.China

   Phone: +8613693578265
   Email: shghuang@bupt.edu.cn
   URI:   http://www.bupt.edu.cn/


   Yun Bai
   BUPT
   No.10,Xitucheng Road,Haidian District
   Beijing  100876
   P.R.China

   Phone: +8618810810306
   Email: byrain@outlook.com
   URI:   http://www.bupt.edu.cn/


   Zhihong Wang
   ZTE Corporation
   No.16,Huayuan Road,Haidian District
   Beijing  100191
   P.R.China

   Phone: +861061198108
   Email: wang.zhihong@zte.com.cn
   URI:   http://www.zte.com.cn/


   Xuping Cao
   ZTE Corporation
   No.16,Huayuan Road,Haidian District
   Beijing  100191
   P.R.China

   Phone: +8613070182356
   Email: cao.xuping@zte.com.cn
   URI:   http://www.zte.com.cn/









Zhang, et al.             Expires July 13, 2013                [Page 12]