Hierarchical PCE Discovery
draft-chen-pce-h-discovery-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Huaimo Chen , Mehmet Toy , Lei Liu , Zhenqiang Li | ||
| Last updated | 2016-10-31 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-pce-h-discovery-01
PCE Working Group H. Chen
Internet-Draft Huawei Technologies
Intended status: Standards Track M. Toy
Expires: May 4, 2017
L. Liu
Fujitsu
Z. Li
China Mobile
October 31, 2016
Hierarchical PCE Discovery
draft-chen-pce-h-discovery-01
Abstract
This document presents extensions to the Path Computation Element
Communication Protocol (PCEP) to discover parent child relations and
the information on a parent and a child PCE in a hierarchical PCE
system.
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 May 4, 2017.
Copyright Notice
Copyright (c) 2016 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
Chen, et al. Expires May 4, 2017 [Page 1]
Internet-Draft H-PCE-Discovery October 2016
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 4
4. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Discovery of Parent Child Relation . . . . . . . . . . . . 4
4.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. Domain Sub-TLV . . . . . . . . . . . . . . . . . . . . 5
4.2.2. PCE ID Sub-TLV . . . . . . . . . . . . . . . . . . . . 6
4.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3.1. Configuration Driven Discovery . . . . . . . . . . . . 7
4.3.2. Auto Discovery . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Chen, et al. Expires May 4, 2017 [Page 2]
Internet-Draft H-PCE-Discovery October 2016
1. Introduction
A hierarchical PCE architecture is described in RFC 6805, in which a
parent PCE has a number of child PCEs. A child PCE may also be a
parent PCE, which has multiple child PCEs.
For a parent PCE, it needs to obtain the information about each of
its child PCEs. The information about a child PCE comprises the
address or ID of the PCE and the domain for which the PCE is
responsible. It may also include the position of the PCE, which
indicates whether the PCE is a leaf (i.e., only a child) or branch
(i.e., a child and also a parent). In addition, the information may
indicate whether the child PCE and its responsible domain is in a
same organization as the parent PCE.
For a child PCE, it needs to obtain the information about its parent
PCE, which includes the address or ID of the parent PCE. The
information may also indicate whether the parent PCE is in a same
organization as the child PCE.
After a user configures a parent PCE and a child PCE over a session,
this parent-child PCE relation needs to be discovered in the protocol
level. This is similar to OSPF and BGP. After an adjacency between
two OSPF routers is configured by a user, the OSPF protocol will
discover the adjacency and forms the OSPF adjacency after the
discovery. After a peer relation between two BGP routers is
configured by a user, the BGP protocol will discover the peer and
forms the BGP peer relation after the discovery.
For a parent-child PCE relation discovery, the PCE protocol needs to
check or confirm whether the parent-child PCE relation is OK (can be
formed). If so, the child PCE has to send its parent PCE the
information about the child PCE and vice versa.
This document presents extensions to the Path Computation Element
Communication Protocol (PCEP) to discover parent child relations and
the information on a parent and a child PCE in a hierarchical PCE
system.
2. Terminology
The following terminology is used in this document.
Parent Domain: A domain higher up in a domain hierarchy such that it
contains other domains (child domains) and potentially other links
and nodes.
Chen, et al. Expires May 4, 2017 [Page 3]
Internet-Draft H-PCE-Discovery October 2016
Child Domain: A domain lower in a domain hierarchy such that it has
a parent domain.
Parent PCE: A PCE responsible for selecting a path across a parent
domain and any number of child domains by coordinating with child
PCEs and examining a topology map that shows domain inter-
connectivity.
Child PCE: A PCE responsible for computing the path across one or
more specific (child) domains. A child PCE maintains a
relationship with at least one parent PCE.
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. Extensions to PCEP
This section describes the extensions to PCEP to discover the
relation between a parent PCE and a child PCE and the information on
a parent and a child PCE in a hierarchical PCE system. A child PCE
is simply called a child and a parent PCE is called a parent in the
following sections.
4.1. Discovery of Parent Child Relation
During a PCEP session establishment between two PCEP speakers, each
of them advertises its capabilities for Hierarchical PCE (H-PCE for
short) through the Open Message with the Open Object containing a new
TLV to indicate its capabilities for H-PCE. This new TLV is called
H-PCE capability TLV. It has the following format.
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 = TBD1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|P|C|S|B| Capability Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Sub-TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chen, et al. Expires May 4, 2017 [Page 4]
Internet-Draft H-PCE-Discovery October 2016
The type of the TLV is TBD1. It has a length of 4 octets plus the
size of optional Sub-TLVs. The value of the TLV comprises a
capability flags field of 32 bits, which are numbered from the most
significant as bit zero. Some of them are defined as follows. The
others are not defined and MUST be set to zero.
o P (Parent - 1 bit): Bit 0 is used as P flag. It is set to 1
indicating a parent.
o C (Child - 1 bit): Bit 1 is used as C flag. It is set to 1
indicating a child.
o S (Same Org - 1 bit): Bit 2 is used as S flag. It is set to 1
indicating a PCE in a same organization as its remote peer.
o B (Both - 1 bit): Bit 3 is used as B flag. It is set to 1
indicating a PCE as both a child and a parent.
The following Sub-TLVs are defined:
o A Domain Sub-TLV containing an AS number and optional area, and
o PCE-ID Sub-TLV containing the ID of a PCE.
4.2. Sub-TLVs
When a child sends its parent a Open message, it places the
information about it in the message through using some optional Sub-
TLVs. When a parent sends each of its child PCEs a Open message, it
puts the information about it in the message.
4.2.1. Domain Sub-TLV
A domain is a AS or an area in an AS. An AS is identified by an AS
number. An area in an AS is identified by the combination of the AS
and the area. The former is indicated by an AS number and the latter
by an area number. A domain is represented by a domain Sub-TLV
containing an AS number and a optional area number.
The format of the domain Sub-TLV is shown below:
Chen, et al. Expires May 4, 2017 [Page 5]
Internet-Draft H-PCE-Discovery October 2016
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional Area Number ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where Length is four plus size of area number.
An AS is represented by a domain Sub-TLV containing only the AS
number of the AS. In this case, the Length is four. An area in an
AS is represented by a domain Sub-TLV containing the AS number of the
AS and the area number of the area. In this case, the Length is
eight.
4.2.2. PCE ID Sub-TLV
An Identifier (ID) of a PCE (PCE ID for short) is a 32-bit number
that can uniquely identify the PCE among all PCEs. This 32-bit
number for PCE ID SHOULD NOT be zero.
The format of the PCE ID Sub-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 (tTBD3) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PCE ID Sub-TLV specifies an non zero number as the identifier of the PCE.
Alternatively, an IP address attached to a PCE can also be used as an
identifier of the PCE. The format of an IPv4 address Sub-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 (tTBD4) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Chen, et al. Expires May 4, 2017 [Page 6]
Internet-Draft H-PCE-Discovery October 2016
The IPv4 address Sub-TLV specifies an IPv4 address associated with
the PCE, which is used as the identifier of the PCE.
The format of an IPv6 address Sub-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 (tTBD5) | Length (16) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The IPv6 Sub-TLV specifies an IPv6 address associated with the PCE,
which is used as the identifier of the PCE.
4.3. Procedures
There are two types of procedures for parent-child PCE relation
discoveries: auto-discovery and configuration driven discovery.
For two PCEs belonging to two different service providers, there are
some security concerns for automatically discovering the parent-child
PCE relation without any configuration. For PCEs belonging to the
same service provider, we can use auto-discovery for discovering the
parent-child PCE relations. This section considers these two types
of discoveries.
4.3.1. Configuration Driven Discovery
For two PCEs A and B configured as parent and child, they discover
each other through Open messages in the initialization phase. The
following is a sequence of events related.
A B
Configure B Configure A
as its child as its parent
Open (P=1, A's ID)
-------------------> Same as configured
A is B's parent
Open (C=1, B's ID)
Same as configured <-------------------
B is A's child
A sends B a Open message with P=1 and A's ID after B is configured as
Chen, et al. Expires May 4, 2017 [Page 7]
Internet-Draft H-PCE-Discovery October 2016
its child on it. B sends A a Open message with C=1 and B's ID after
A is configured as its parent on it.
When A receives the Open message from B and determines C=1 and the
PCE ID of B in the message is the same as the PCE ID of the child
locally configured, B is A's child.
When B receives the Open message from A and determines P=1 and the
PCE ID of A in the message is the same as the PCE ID of the parent
locally configured, A is B's parent.
The Open message from child B to its parent A contains B's domain,
which is represented by a domain Sub-TLV in the H-PCE capability TLV.
If child B is also a parent, the B flag in the TLV is set to 1.
The PCE ID in a Open message may be represented in one of the
following ways:
o The source IP address of the message (i.e., PCE session).
o A PCE ID Sub-TLV in the H-PCE capability TLV.
o An IP address Sub-TLV in the H-PCE capability TLV.
When the IP address Sub-TLV is used, the address in the Sub-TLV MUST
be the same as the source IP address of the PCE session.
For a child that is a leaf, it is normally responsible for one
domain, which is contained in the message to its parent.
For a child that is a branch (i.e., also a parent of multiple child
PCEs), it may be directly responsible for one domain, which is
contained in the message to its parent. In addition, it is
responsible for the domains of its child PCEs. In other words, it is
responsible for computing paths crossing the domains through working
together with its child PCEs. If these domains are all areas of an
AS, the AS is included in the message to its parent.
A parent stores the information about each of its child PCEs
received. When the session to one of them is down, it removes the
information about the child on that session.
A child stores the information about its parent received. When the
session to the parent is down, it removes the information about the
parent.
If there already exists a session between A and B and the
configurations on parent and child are issued on them, the procedures
Chen, et al. Expires May 4, 2017 [Page 8]
Internet-Draft H-PCE-Discovery October 2016
above may be executed through bringing down the existing session and
establishing a new session between them. Alternatively, they may
discover each other regarding to H-PCE through using extended
Notification messages in the same procedures as using Open messages
described above without bringing down the existing session.
The following new Notification-type and Notification-value are
defined for H-PCE:
o Notification-type=5 (TBD): Discovery of H-PCE
* Notification-value=1: The information about a parent PCE or a
child PCE. A Notification-type=5, Notification-value=1
indicates that the PCE sends its peer the information about it
and a TLV containing the information is in the Notification
object. The format and contents of the TLV is the same as the
H-PCE capability TLV described above. The only difference may
be the type of the TLV.
4.3.2. Auto Discovery
For two PCEs A and B belonging to the same service provider, their
parent-child PCE relation may be automatically discovered without any
configuration or with minimum configuration.
For a parent-child PCE relation between two PCEs A and B to be
automatically discovered, two conditions need to be met. One is that
both A and B know that they are in the same service provider. The
other is that one of them determines that it is the parent or child.
After these two conditions are met, A and B may automatically
discover their parent-child relation through exchanging the messages
in a way similar to the one described in the previous section.
If A (or B) is a child of another PCE X over the session between X
and A (or B), then it can determine that it is the parent over the
session between A and B. After the parent is determined between A and
B, the child is implied.
If A (or B) is not any child of a PCE, then it can not determine
whether it is a parent or child over the session between A and B. In
this case, a configuration on A or B is needed to indicate the parent
or child.
Two PCEs A and B may know that they are in the same service provider
through their domains. In general, the areas in an AS belong to a
same service provider. After PCEs A and B know that they are
responsible for the areas in the same AS, they know that they are in
Chen, et al. Expires May 4, 2017 [Page 9]
Internet-Draft H-PCE-Discovery October 2016
the same service provider.
For two PCEs A and B responsible for two different ASes, it is hard
for them to determine whether they are in the same service provider.
In this case, a configuration on A and B is needed to indicate they
are in the same service provider.
5. Security Considerations
The mechanism described in this document does not raise any new
security issues for the PCEP protocols.
6. IANA Considerations
This section specifies requests for IANA allocation.
7. Acknowledgement
The authors would like to thank people for their valuable comments on
this draft.
8. References
8.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>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012,
<http://www.rfc-editor.org/info/rfc6805>.
[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>.
8.2. Informative References
[RFC4105] Le Roux, J., Ed., Vasseur, J., Ed., and J. Boyle, Ed.,
"Requirements for Inter-Area MPLS Traffic Engineering",
RFC 4105, DOI 10.17487/RFC4105, June 2005,
<http://www.rfc-editor.org/info/rfc4105>.
Chen, et al. Expires May 4, 2017 [Page 10]
Internet-Draft H-PCE-Discovery October 2016
[RFC4216] Zhang, R., Ed. and J. Vasseur, Ed., "MPLS Inter-Autonomous
System (AS) Traffic Engineering (TE) Requirements",
RFC 4216, DOI 10.17487/RFC4216, November 2005,
<http://www.rfc-editor.org/info/rfc4216>.
[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>.
Authors' Addresses
Huaimo Chen
Huawei Technologies
Boston, MA,
USA
EMail: Huaimo.chen@huawei.com
Mehmet Toy
USA
EMail: mtoy054@yahoo.com
Lei Liu
Fujitsu
USA
EMail: lliu@us.fujitsu.com
Zhenqiang Li
China Mobile
No.32 Xuanwumenxi Ave., Xicheng District
Beijing 100032
P.R. China
EMail: li_zhenqiang@hotmail.com
Chen, et al. Expires May 4, 2017 [Page 11]