PCEP Link State AbstractionFutureweiBoston, MAUSAHuaimo.chen@futurewei.comVerizonUSAmehmet.toy@verizon.comVolta NetworksMcLeanVAUSAxufeng.liu.ietf@gmail.comFujitsuUSAliulei.kddi@gmail.comChina MobileNo.32 Xuanwumenxi Ave., Xicheng DistrictBeijing100032P.R. Chinali_zhenqiang@hotmail.com
Routing
PCE Working Group
This document presents extensions to
the Path Computation Element Communication Protocol (PCEP)
for a child PCE to abstract its domain information to its parent
for supporting a hierarchical PCE system.
A hierarchical PCE architecture is described in RFC 6805, in which a parent PCE maintains an abstract domain topology, which contains its child domains (seen as vertices in the topology) and the connections among them.
For a domain for which a child PCE is responsible, connections attached to the domain may comprise inter-domain links and Area Border Routers (ABRs).
For a parent PCE to have the abstract domain topology, each of its child PCEs needs to advertise its connections to the parent PCE.
In addition to the connections attached to the domain, there may be some access points in the domain, which are the addresses in the domain to be accessible outside of the domain. For example, an address of a server in the domain that provides a number of services to users outside of the domain is an access point.This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a child PCE to advertise the information about its connections and access points to its parent PCE and
for the parent PCE to build and maintain the abstract domain topology based on the information.
The extensions may reduce configurations,
thus simplify operations on a PCE system.
A child PCE is simply called a child
and a parent PCE is called a parent in the following sections.
Area Border Router. Router used to connect two IGP areas (Areas in OSPF or levels in IS-IS).Autonomous System (AS) Border Router. Router used to connect together ASes via inter-AS links.Traffic Engineering Database.This document uses terminology defined in .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 .A connection is an inter-domain link between two domains
in general.
An ABR is also a connection, which connects two special domains
called areas in a same Autonomous System (AS).
An access point in a domain is an address in the domain
to be accessible to the outside of the domain.
An access point is simply called an access.
An inter-domain link connects two domains
in two different ASes.
Since there is no IGP running over an inter-domain link,
we may not obtain the information about the link generated
by an IGP.
We may suppose
that IP addresses are configured on inter-domain links.
For a point-to-point (P2P) link connecting two ABSRs A and B
in two different domains,
from A's point of view, the following information about
the link may be obtained:
We will have a link ID if it is configured;
otherwise 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 ASBRs
in a number of domains,
on each of the ASBRs X, the same information about the link
as above may be obtained
except for the followings:
In other words,
the information about the broadcast link obtained by ASBR X
comprises a), b), 4) to 9),
but does not include any remote IP address or link ID.
We will have a link ID if it is configured;
otherwise no link ID (i.e., the interface address of the designated
router for the link) may be obtained since no IGP selects it.
A parent constructs an abstract AS domain topology
after receiving the information about each of the inter-domain links
described above from its children.
RFC 5392 and RFC 5316 describe the distributions
of inter-domain links in OSPF and IS-IS respectively.
For each inter-domain link,
its neighboring AS number and
neighboring ASBR Identity (TE Router ID) need to be configured
in IGP (OSPF or IS-IS). In addition,
an IGP adjacency between a network node running IGP and
a PCE running IGP as a component needs to be configured
and fully established
if we want the PCE to obtain the inter-domain link
information from IGP.These configurations and IGP adjacency establishment
are not needed if the extensions in this draft are used.
RFC 7752 (BGP-LS) describes the distributions of TE link state
information including inter-domain link state.
A BGP peer between a network node running BGP and
a PCE running BGP as a component needs to be configured and
the peer relation must be established
before the PCE can obtain the inter-domain link information
from BGP.
However, some networks may not run BGP.
For an AS running IGP and containing multiple areas,
an ABR connects two or more areas.
For each area connected to the ABR,
the PCE as a child responsible for the area sends its parent
the information about the ABR,
which indicates the identifier (ID) of the ABR.
A parent has the information about each of its children,
which includes the domain such as the area
for which the child is responsible.
The parent knows all the areas to which each ABR connects
after receiving the information on the ABR from each of its children.
For an IP address in a domain to be accessible outside
of the domain,
the PCE as a child responsible for the domain sends its parent
the information about the address.
The parent has all the access points (i.e., IP addresses)
to be accessible outside of all its children' domains
after receiving the information on the access points
from each of its children.
This section focuses on procedures for abstracting domain
information after briefing messages containing the abstract
information.
A child abstracts its domain to its parent through
sending its parent a message containing the abstract information
on the domain.
After the relation between the child and the parent is determined,
the parent has some information on the child, which includes
the child's ID and domain.
The message does not need to contain this information.
It comprises the followings:
For new or updated Connections and Accesses,
Indication of Update Connections and Accesses Detail Information about Connections and Accesses For Connections and Accesses down,
Indication of Withdraw Connections and Accesses ID Information about Connections and AccessesFor a P2P link from ASBR A to B and a broadcast link connecting to A,
the detail information on the links includes
A's ID, the information on the P2P link and
the information on the broadcast link
described in Section 4.
The ID information on the links includes
A's ID, 1) to 3) for the P2P link and a) to b) for the broadcast link
described in Section 4.
A link ID for a link is included if it is configured.
For an ABR X,
the information on X includes X's ID and a flag indicating that X is ABR.
For an Access X (address),
the detail information on X includes X and a cost associated with it.
The ID information on X is X itself.
There are a few ways to encode the information above
into a message.
For example, one way is to extend an existing Notification message for
including the information.
Another way is to use a new message.
These are put in Appendix A for your reference.
After a child determines its parent, it sends the parent
a message containing the information about
the connections (i.e., inter-domain links and ABRs)
from its domain to its adjacent domains and
the access points in its domain.For any new or changed inter-domain links, ABRs and
access points in the domain for which a child is responsible,
the child sends its parent a message containing the information
about these links, ABRs and access points
with indication of Update Connections and Accesses.
For example, for a new inter-domain P2P link
from ASBR A in a child's domain to ASBR B in another domain,
the child sends its parent a message containing
an indication of Update Connections and Accesses,
A's ID, and the detail information on the link described
in section 4.1.
For multiple new or changed inter-domain links from ASBR A,
the child sends its parent a message having
an indication of Update Connections and Accesses,
and A's ID
followed by the detail information about each of the links.
In another example,
for a new or changed inter-domain broadcast link connected
to ASBR X, an ABR Y and an access point 10.10.10.1/32 with cost 10
in a child's domain,
the child sends its parent a message containing
an indication of Update Connections and Accesses,
and X's ID
followed by the detail information about the link attached to X
and the detail information about ABR Y, and
the information on access 10.10.10.1/32 with cost 10.
For changes on the attributes (such as bandwidth)
of an inter-domain link,
a threshold may be used to control the frequency of updates
that are sent from a child to its parent.
At one extreme, the threshold is set to let
a child send its parent a update message for any change on
the attributes of an inter-domain link.
At another extreme, the threshold is set to make
a child not to send its parent any update message
for any change on the attributes of an inter-domain link.
Typically, the threshold is set to allow
a child to send its parent a update message
for a significant change
on the attributes of an inter-domain link.
For any inter-domain links, ABRs and access points down
in the domain for which a child is responsible,
the child sends its parent a message containing the information
about these links, ABRs and access points
with indication of Withdraw Connections and Accesses.
For example, for the inter-domain P2P link
from ASBR A down,
the child sends its parent a message containing
an indication of Withdraw Connections and Accesses,
and A's ID, which is
followed by the ID information about the link.
For multiple inter-domain links from ASBR A down,
the child sends its parent a message having
an indication of Withdraw Connections and Accesses,
and A's ID, which is
followed by the ID information about each of the links.
If a child and its parent are in a same organization,
the child may send its parent the information inside its domain.
For a parent,
after all its children in its organization send their parent
the information in their domains, connections and access points,
it has in its TED the detail information inside each of
its children's domains and the connections among these domains.
The parent can compute a path crossing these domains directly
and efficiently
without sending any path computation request to its children.
There are a few ways in which a child as a parent
abstracts its domain information to its parent.
One way is that the child sends its parent
all its domain information
if the child and the parent are in a same organization.
The information includes the detail network topology
inside each of the child's domains,
the inter-domain links connecting the domains
that the child's children are responsible
and the inter-domain links connecting these domains to other
adjacent domains.
In another way, the child abstracts
each of the domains that its children are responsible
as a cloud (or say abstract node) and
these clouds are connected by the inter-domain
links attached to the domains.
The child sends its parent
all the inter-domain links attached to any of the domains.
In a third way, the child abstracts
all its domains including the domains
for which its children are responsible
as a cloud.
This abstraction is described below in details.
If a parent P1 is also a child of another parent P2,
P1 as a child sends its parent P2 a message containing
the information about the connections and access points.
P1 as a parent has the connections among its children's domains.
But these connections are hidden from its parent P2.
P1 may have connections from its children's domains to other domains.
P1 as a child sends its parent P2 these connections.
P1 as a parent has the access points in its children's
domains to be accessible outside of the domains.
P1 as child may not send all of these to its parent P2.
It sends its parent some of these access points
according to some local policies.
From P2's point of view, its child P1 is responsible
for one domain, which has some connections to its adjacent
domains and some access points to be accessible.
A parent stores into its TED
the connections and accesses for each of its children
according to the messages containing connections and
accesses received.
For a message containing Update Connections and Accesses,
it updates the connections and accesses in the TED accordingly.
For a message containing Withdraw Connections and Accesses,
it removes the connections and accesses from the TED.
After receiving the messages for connections and accesses
from its children,
the parent builds and maintains the TED
for the topology of its children's domains,
in which each of the domains is seen as a cloud or an abstract node.
The information inside each of the domains is hidden from the parent.
There are connections among the domains and
the access points in the domains to be accessible in the topology.
For a new P2P link from node A to B with no link ID configured,
when receiving a message containing the link from a child,
the parent stores the link from A into its TED,
where A is attached to the child's domain as a cloud.
It finds the link's remote end B using the remote IP address of the link.
After finding B, it associates the link attached to A
with B and the link attached to B with A.
This creates a bidirectional connection between A and B.
For a new P2P link from node A to B with link ID configured,
when receiving a message containing the link,
the parent stores the link from A into its TED.
It finds the link's remote end B using the link ID (i.e., B's ID).
For a new broadcast link connecting multiple nodes with no link ID
configured, when the parent receives a message containing the link
attached to node X, it stores the link from X into its TED.
It finds the link's remote end P
using the link's local IP address with network mask. P is a Pseudo
node identified by the local IP address of the designated node
selected from the nodes connected to the link. After finding P, it
associates the link attached to X with P and
the link connected to P with X.
If P is not found, a new Pseudo node P is created.
The parent associates the link attached to X with P and
the link attached to P with X.
This creates a bidirectional connection between X and P.
The first node and second node from which the parent receives
a message containing the link is selected as the designed node and
backup designed node respectively. After the designed node is down, the
backup designed node becomes the designed node and the node other
than the designed node with the largest local IP address connecting
to the link is selected as the backup designed node.
When the old designed node is down and the backup designed node
becomes the new designed node, the parent updates its TED through
removing the link between each of nodes X and old P (the Pseudo node
corresponding to the old designed node) and adding a link between
each of nodes X (still connecting to the broadcast link) and new P
(the Pseudo node corresponding to the new designed node).
If a parent is in a same organization as its child,
it stores into its TED the detail information inside the child's
domain when receiving a message containing the information
from the child;
otherwise, it discards the information and issues a warning
indicating that the information is sent to a wrong place.
The mechanism described in this document does not raise any new security issues for the PCEP protocols.This section specifies requests for IANA allocation.The authors would like to thank Jescia Chen, Adrian Farrel,
and Eric Wu for their valuable comments on this draft.An existing Notification message may be extended
to advertise the information about connections and access points.
The following new Notification-type (NT) and Notification-value (NV)
of a NOTIFICATION object in the message are defined:
NT=8 (TBD): Connections and Accesses
NV=1: Update Connections and Accesses.
A NT=8 and NV=1 indicates that the
child sends its parent updates on the information
about Connections and Accesses, and
TLVs containing the information are in the object.
NV=2: Withdraw Connections and Accesses.
A NT=8 and NV=2 indicates that the
child asks its parent to remove Connections and Accesses
indicated by TLVs in the object.Four TLVs are defined for connections and accesses.
They are Inter-Domain link TLV, Router-ID TLV,
Access IPv4/IPv6 Prefix TLV.
The format of the Inter-Domain link TLV is illustrated below.
An Inter-Domain link TLV describes a single inter-domain link.
It comprises a number of inter-domain 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.
Undefined flags MUST be set to zero.
The ID indicates the ID of a router.
For a router running OSPF, the ID may be the 32-bit OSPF router ID
of the router.
For a router running IS-IS, the ID may be the 48-bit IS-IS router ID
of the router.
For a router not running OSPF or IS-IS,
the ID may be the 32-bit ID of the router configured.
The format of the Access IPv4/IPv6 Prefix TLV is shown as follows.
The cost is the metric to the prefix.
The Prefix Length indicates the length of the prefix.
The IPv4/IPv6 Prefix indicates an access IPv4/IPv6 address prefix.
The format of the Sub-TLV for a local IPv4/IPv6 address with
mask length is shown as follows.
The IPv4/IPv6 Address indicates the local IPv4/IPv6 address of a link.
The Mask Length indicates the length of the IPv4/IPv6 address mask.
A new message may be defined to advertise the connections
and accesses from a child to its parent.
The format of the message containing Connections and
Access (AC for short) is as follows:
::= []
where:
::= []
::= [ | ]
::= []
]]>
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 connections and access are withdrawn.
When flag W is set to one, the parent removes the connections
and accesses contained in the message after receiving it.
When flag W is set to zero, the parent adds/updates
the connections and accesses in the message after receiving it.
An alternative to flag W in the NRP object is a similar flag
in each CONNECTION and ACCESS 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 parent removes the connections and accesses in the object
after receiving it.
When the flag is set to zero in the object,
the parent adds/updates the connections and accesses
in the object after receiving it.
In another option, one byte in a CONNECTION and ACCESS 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.
The objects in the new message are defined below.
A new object, called CONNECTION and ACCESS Object
(CA for short), is defined. It has Object-Class ocTBD1.
Four Object-Types are defined under CA object:
CA Inter-Domain Link: CA Object-Type is 1.CA ABR: CA Object-Type is 2.CA Access IPv4 Prefix: CA Object-Type is 3.CA Access IPv6 Prefix: CA Object-Type is 4.
Each of these objects are described below.
The format of Inter-Domain Link object body is as follows:
The Router-ID TLV indicates an ASBR in the domain,
which is a local end of inter-domain links.
Each of the Inter-Domain Link TLVs describes an inter-domain link
and comprises a number of inter-domain link Sub-TLVs.
Flag W=1 indicates withdraw the links.
W=0 indicates new or changed links.
The format of ABR object body is illustrated below:
Each of the Router-ID TLVs indicates an ABR in the domain.
Flag W=1 indicates withdraw the ABRs.
W=0 indicates new ABRs.
The format of Access IPv4/IPv6 Prefix object body is as follows:
Each of the Access IPv4/IPv6 Prefix TLVs describes an access IPv4/IPv6 address
prefix in the domain, which is accessible to outside of the domain.
Flag W=1 indicates withdraw the address prefixes.
W=0 indicates new address prefixes.
The TLVs in the objects are the same as those described above.