PCE Working Group H. Chen
Internet-Draft Huawei Technologies
Intended status: Standards Track July 7, 2016
Expires: January 8, 2017
Native PCE TED
draft-chen-pce-pcc-ted-00
Abstract
This document presents extensions to the Path Computation Element
Communication Protocol (PCEP) for a PCC to advertise the information
about the links and for a PCE to build a TED based on the information
received.
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 8, 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
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.
Chen Expires January 8, 2017 [Page 1]
Internet-Draft PCE-TED July 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 3
4. Information on Link . . . . . . . . . . . . . . . . . . . . . 3
5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Extension to Existing Message . . . . . . . . . . . . . . 4
5.1.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. PCC Procedures . . . . . . . . . . . . . . . . . . . . 7
5.2.2. PCE Procedures . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. New Message . . . . . . . . . . . . . . . . . . . . . 10
A.1. LINK Object . . . . . . . . . . . . . . . . . . . . . . . 10
A.2. TLVs in LINK Object . . . . . . . . . . . . . . . . . . . 11
Chen Expires January 8, 2017 [Page 2]
Internet-Draft PCE-TED July 2016
1. Introduction
A PCE architecture is described in RFC 4655, in which the TED for a
PCE is constructed through using routing protocol such as OSPF or
IS-IS running in the domain for which the PCE is resposible.
For a domain without running OSPF or IS-IS, the PCE responsible for
the domain may obtain the inforamtion about the links from each of
the PCCs running on a node in the domain.
This document presents extensions to the Path Computation Element
Communication Protocol (PCEP) for a PCC to advertise the information
about the links attached to the node running the PCC and for a PCE to
build a TED based on the information received from the PCC.
2. Terminology
The following terminology is used in this document.
ABR: Area Border Router. Router used to connect two IGP areas
(Areas in OSPF or levels in IS-IS).
ASBR: Autonomous System Border Router. Router used to connect
together ASes of the same or different service providers via one
or more inter-AS links.
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. Information on Link
Since there is no IGP running over any link, we may not obtain the
information about the link generated by an OSPF or IS-IS. We may
suppose that IP addresses are configured on links.
For a point-to-point link connecting two nodes A and B, from A's
point of view, the following information about the link may be
obtained:
Chen Expires January 8, 2017 [Page 3]
Internet-Draft PCE-TED July 2016
1) Link Type: Point-to-point
2) Local IP address of the link
3) Remote IP address of the link
4) Traffic engineering metric of the link
5) Maximum bandwidth of the link
6) Maximum reservable bandwidth of the link
7) Unreserved bandwidth of the link
8) Administrative group of the link
Note that no link ID (i.e., the Router ID of the neighbor) may be
obtained since no IGP adjacency over the link is formed.
For a broadcast link connecting multiple nodes, on each of the nodes
X, the same information about the link as above may be obtained
except for the followings:
a) Link Type: Multi-access,
b) Local IP address with mask length, and
c) No Remote IP address.
In other words, the information about the broadcast link obtained by
node X comprises a), b), 4), 5), 6), 7) and 8), but does not include
any remote IP address or link ID. Note that no link ID (i.e., the
interface address of the designated router for the link) may be
obtained since no IGP selects it.
A PCE constructs a TED for the domain for which the PCE is
responsible after receiving the information about each of the links
described above from the PCC running on every node in the domain plus
the node ID such as A's ID.
5. Extensions to PCEP
This section describes the extensions to PCEP to distribute the
information about links.
5.1. Extension to Existing Message
An existing Notification message may be extended to advertise the
information about links. Alternatively, a new message can be used
(refer to Appendix A).
The following new Notification-type (NT) and Notification-value (NV)
of a NOTIFICATION object in a Notification message are defined:
Chen Expires January 8, 2017 [Page 4]
Internet-Draft PCE-TED July 2016
o NT=8 (TBD): Links
* NV=1: Updates on Links. A NT=8 and NV=1 indicates that the PCC
sends the PCE updates on the information about Links, and TLVs
containing the information are in the NOTIFICATION object. The
format and contents of the TLVs are described below.
* NV=2: Withdraw Links. A NT=8 and NV=2 indicates that the PCC
asks the PCE to remove Links indicated by the TLVs in the
object.
5.1.1. TLVs
Two TLVs are defined for the information on links. They are link TLV
and Router-ID TLV.
The format of the link TLV is illustrated below. The Type=tTBD1
indicates a link TLV Type. The Length indicates the size of the Link
Sub-TLVs.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Sub-TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A link TLV describes a single link. It comprises a number of link
sub-TLVs for the information described in section 4, which are the
sub-TLVs defined in RFC 3630 or their equivalents except for the
local IP address with mask length defined below.
The format of the Router-ID TLV is shown below. The Type=tTBD2
indicates a Router-ID TLV Type. The Length indicates the size of the
ID and flags field.
Chen Expires January 8, 2017 [Page 5]
Internet-Draft PCE-TED July 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 (tTBD2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|E|I| Flags | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| 32-bit/48-bit ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flag B: Set to 1 indicating ABR (B is for Border)
Flag E: Set to 1 indicating ASBR (E is for External)
Flag I: Set to 1 indicating ID of local router (I is for ID)
Undefined flags MUST be set to zero. The ID indicates the ID of a
router. For a router not running OSPF or IS-IS, the ID may be the
32-bit or 48-bit ID of the router configured.
5.1.2. Sub-TLVs
The format of the Sub-TLV for a local IPv4 address with mask length
is shown as follows. The Type=stTBD1 indicates a local IPv4 Address
with mask length. The Length indicates the size of the IPv4 address
and Mask Length. The IPv4 Address indicates the local IPv4 address
of a link. The Mask Length indicates the length of the IPv4 address
mask.
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 (stTBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask Length |
+-+-+-+-+-+-+-+-+
The format of the Sub-TLV for a local IPv6 address with mask length
is illustrated below. The Type=stTBD2 indicates a local IPv6 Address
with mask length. The Length indicates the size of the IPv6 address
and Mask Length. The IPv6 Address indicates the local IPv6 address
of a link. The Mask Length indicates the length of the IPv6 address
mask.
Chen Expires January 8, 2017 [Page 6]
Internet-Draft PCE-TED July 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 (stTBD2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask Length |
+-+-+-+-+-+-+-+-+
5.2. Procedures
5.2.1. PCC Procedures
1. New or Changed Links
After the session between a PCC and a PCE is established, the PCC
sends the PCE a message containing the information about the links
attached to the node running the PCC.
When there are changes on the links, the PCC sends the PCE a message
for the changed links.
For any new or changed links, the PCC sends the PCE a message
containing the information about these links with indication of
Updates on Links.
For example, for a new point-to-point link from node A to node B, the
PCC running on node A may send the PCE a Notification message having
a NOTIFICATION object with NT=8 and NV=1 (indicating Updates on
Links), which contains a Router-ID TLV, followed by a link TLV. The
Router-ID TLV comprises the ID of node A and flag I set to 1. The
link TLV comprises the Sub-TLVs for the information on 1) to 8)
described in section 4.
For multiple new or changed links from node A, the PCC running on A
may send the PCE a Notification message having a NOTIFICATION object
with NT=8 and NV=1, which contains a Router-ID TLV for the ID of node
A, followed by multiple link TLVs for the links from node A. Thus
this one message contains the information about multiple links.
2. Links Down
For any links down, the PCC sends the PCE a message containing the
information about these links with indication of Withdraw Links.
Chen Expires January 8, 2017 [Page 7]
Internet-Draft PCE-TED July 2016
For example, for the point-to-point link from node A to node B down,
the PCC running on node A may send the PCE a Notification message
having a NOTIFICATION object with NT=8 and NV=2 (indicating Withdraw
Links), which contains a Router-ID TLV, followed by a link TLV. The
Router-ID TLV comprises the ID of node A and flag I set to 1. The
link TLV comprises the Sub-TLVs for the information on 1), 2) and 3)
described in section 4.
For multiple links from node A down, the PCC running on node A may
send the PCE a Notification message having a NOTIFICATION object with
NT=8 and NV=2, which contains a Router-ID TLV for the ID of node A,
followed by multiple link TLVs for the links from node A. The TLV for
a point-to-point link comprises the Sub-TLVs for the information on
1), 2) and 3) described in section 4. The TLV for a broadcast link
comprises the Sub-TLVs for the information on a) and b) described in
section 4.
3. Simplified Message
Alternatively, the messages may be simplified and the PCC procedures
may change accordingly.
For each node, the source IP address of the PCC running on the node
may be used as the ID of the node. The PCE knows the address after
the session between the PCE and the PCC is up. When the session
between the PCE and the PCC is established, the PCC may send the PCE
an ID of the node configured. Thus, a message containing the
information about links does not need include any router-ID TLV.
For example, for a new point-to-point link attached to node A, the
PCC running on node A sends the PCE a Notification message having a
NOTIFICATION object with NT=8 and NV=1 (indicating Updates on Links),
which contains a link TLV comprising the Sub-TLVs for the information
on 1) to 8) described in section 4. The object does not contain any
Router-ID TLV for node A.
In another example, for multiple links attached to node A down, the
PCC running on node A sends the PCE a Notification message having a
NOTIFICATION object with NT=8 and NV=2 (indicating Withdraw Links),
which contains multiple link TLVs for the links, but does not contain
any Router-ID TLV for node A. The TLV for a point-to-point link
comprises the Sub-TLVs for the information on 1), 2) and 3) described
in section 4. The TLV for a broadcast link comprises the Sub-TLVs
for the information on a) and b) described in section 4.
Chen Expires January 8, 2017 [Page 8]
Internet-Draft PCE-TED July 2016
5.2.2. PCE Procedures
A PCE stores the links for each node according to the messages for
the links received from the PCC running on the node. For a message
containing updates on links, it updates the links accordingly. For a
message containing withdraw links, it removes the links.
When a node is down, the PCE removes the links attached to the node.
After receiving the messages for links from the PCCs, the PCE builds
and maintains a TED for the PCE's domain.
6. Security Considerations
The mechanism described in this document does not raise any new
security issues for the PCEP protocols.
7. IANA Considerations
This section specifies requests for IANA allocation.
8. Acknowledgement
The authors would like to thank Eric Wu and others for their valuable
comments on this draft.
9. References
9.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>.
[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>.
[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>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
Chen Expires January 8, 2017 [Page 9]
Internet-Draft PCE-TED July 2016
<http://www.rfc-editor.org/info/rfc3630>.
9.2. Informative References
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<http://www.rfc-editor.org/info/rfc7752>.
Appendix A. New Message
A new message may be defined to advertise the information on links.
The format of the message containing the inforamtion on Links (IL for
short) is as follows:
<IL Message> ::= <Common Header>
<NRP>
<Link-List>
where:
<Link-List> ::= <LINK> [<Link-List>]
Where the value of the Message-Type in the Common Header indicates
the new message type. The exact value is to be assigned by IANA. A
new RP (NRP) object will be defined, which follows the Common Header.
A new flag W (Withdraw) in the NRP object is defined to indicate
whether the links are withdrawn. When flag W is set to one, the PCE
removes the links contained in the message after receiving it from
the PCC. When flag W is set to zero, the PCE adds/updates the links
in the message.
An alternative to flag W in the NRP object is a similar flag in each
LINK object such as using one bit in Res flags for flag W. For
example, when the flag is set to one in the object, the PCE removes
the links in the object after receiving it. When the flag is set to
zero in the object, the PCE adds/updates the links in the object.
In another option, one byte in a LINK Object is defined as flags
field and one bit is used as flag W. The other undefined bits in the
flags field MUST be set to zero.
A.1. LINK Object
A new object, called LINK Object is defined. The format of LINK
object body is as follows:
Chen Expires January 8, 2017 [Page 10]
Internet-Draft PCE-TED July 2016
Object-Class = ocTBD1 (LINK)
Object-Type = 1 (Link)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|W| Flags | Router-ID TLV |
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Router-ID TLV indicates a node in the domain, which is a local
end of links. Each of the Link TLVs describes a link and comprises a
number of link Sub-TLVs. Flag W=1 indicates withdraw the links. W=0
indicates new or changed links.
A.2. TLVs in LINK Object
The format of the Router-ID TLV is illustrated 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 (tTBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit/48-bit ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The format of the link 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 (tTBD2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Sub-TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The link sub-TLVs are for the information on a link described in
section 4, which are the sub-TLVs defined in RFC 3630 or their
equivalents except for local IP address with mask length.
Chen Expires January 8, 2017 [Page 11]
Internet-Draft PCE-TED July 2016
Author's Address
Huaimo Chen
Huawei Technologies
Boston, MA,
USA
EMail: Huaimo.chen@huawei.com
Chen Expires January 8, 2017 [Page 12]