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

Abstract

In real networks, the link between two adjacent nodes always has multi-fibers. The 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-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.

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 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 January 08, 2013.

Copyright Notice

Copyright (c) 2012 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
• 1.1. PCE discovery
• 1.2. TED of parent PCE
• 1.3. Communication of domain connection information
• 2. Conventions Used in This Document
• 3. Terminologies
• 4. Procedure
• 5. PCEP Protocol Extension
• 6. IANA Considerations
• 7. Security Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

In real networks, the link between two adjacent nodes always has multi-fibers. The 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-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 the 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 service requests can be met. However, only one of the three requests can be allocated with 10Gb/s and the other two requests will fail. If the detail information of fiber in this link can be known, the three requests for 10Gb/s will not be accepted 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 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:

• Identifier of advertising child PCE
• Identifier of PCE's domain
• Identifier of the link
• TE properties of the link (metrics, bandwidth)
• Other properties of the link (technology-specific)
• Identifier of link end-points
• Identifier of adjacent domain

It may be desirable for this information to be periodically updated, 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 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 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:

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

6. IANA Considerations

TBD.

7. Security Considerations

TBD.

8. References

8.1. Normative References

8.2. Informative References

Authors' Addresses