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]
