PCEP Link State Abstraction
draft-chen-pce-h-connect-access-08
PCE Working Group H. Chen
Internet-Draft Futurewei
Intended status: Standards Track M. Toy
Expires: July 10, 2021 Verizon
X. Liu
Volta Networks
L. Liu
Fujitsu
Z. Li
China Mobile
January 6, 2021
PCEP Link State Abstraction
draft-chen-pce-h-connect-access-08
Abstract
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.
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 https://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 July 10, 2021.
Copyright Notice
Copyright (c) 2021 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
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Chen, et al. Expires July 10, 2021 [Page 1]
Internet-Draft H-Connect-Access January 2021
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conventions Used in This Document . . . . . . . . . . . . . . 3
4. Connections and Accesses . . . . . . . . . . . . . . . . . . 3
4.1. Information on Inter-domain Link . . . . . . . . . . . . 4
4.2. Information on ABR . . . . . . . . . . . . . . . . . . . 5
4.3. Information on Access Point . . . . . . . . . . . . . . . 5
5. Extensions to PCEP . . . . . . . . . . . . . . . . . . . . . 5
5.1. Messages for Abstract Information . . . . . . . . . . . . 6
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 6
5.2.1. Child Procedures . . . . . . . . . . . . . . . . . . 6
5.2.2. Parent Procedures . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Message Encoding . . . . . . . . . . . . . . . . . . 12
A.1. Extension to Existing Message . . . . . . . . . . . . . . 12
A.1.1. TLVs . . . . . . . . . . . . . . . . . . . . . . . . 12
A.1.2. Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 13
A.2. New Message . . . . . . . . . . . . . . . . . . . . . . . 14
A.2.1. CONNECTION and ACCESS Object . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
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.
Chen, et al. Expires July 10, 2021 [Page 2]
Internet-Draft H-Connect-Access January 2021
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.
2. Terminology
ABR: Area Border Router. Router used to connect two IGP areas
(Areas in OSPF or levels in IS-IS).
ASBR: Autonomous System (AS) Border Router. Router used to connect
together ASes via 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. Connections and Accesses
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.
Chen, et al. Expires July 10, 2021 [Page 3]
Internet-Draft H-Connect-Access January 2021
4.1. Information on Inter-domain Link
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:
1) Link Type: P2P
2) Local IP address
3) Remote IP address
4) Traffic engineering metric
5) Maximum bandwidth
6) Maximum reservable bandwidth
7) Unreserved bandwidth
8) Administrative group
9) SRLG
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:
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
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,
Chen, et al. Expires July 10, 2021 [Page 4]
Internet-Draft H-Connect-Access January 2021
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.
4.2. Information on ABR
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.
4.3. Information on Access Point
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.
5. Extensions to PCEP
This section focuses on procedures for abstracting domain information
after briefing messages containing the abstract information.
Chen, et al. Expires July 10, 2021 [Page 5]
Internet-Draft H-Connect-Access January 2021
5.1. Messages for 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:
o For new or updated Connections and Accesses,
* Indication of Update Connections and Accesses
* Detail Information about Connections and Accesses
o For Connections and Accesses down,
* Indication of Withdraw Connections and Accesses
* ID Information about Connections and Accesses
For 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.
5.2. Procedures
5.2.1. Child Procedures
5.2.1.1. New or Changed Connections and Accesses
After a child determines its parent, it sends the parent a message
containing the information about the connections (i.e., inter-domain
Chen, et al. Expires July 10, 2021 [Page 6]
Internet-Draft H-Connect-Access January 2021
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.
5.2.1.2. Connections and Accesses Down
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
Chen, et al. Expires July 10, 2021 [Page 7]
Internet-Draft H-Connect-Access January 2021
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.
5.2.1.3. Child and Parent in Same Organization
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.
5.2.1.4. Child as a Parent
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.
Chen, et al. Expires July 10, 2021 [Page 8]
Internet-Draft H-Connect-Access January 2021
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.
5.2.2. Parent Procedures
5.2.2.1. Process Connections and Accesses
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
Chen, et al. Expires July 10, 2021 [Page 9]
Internet-Draft H-Connect-Access January 2021
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).
5.2.2.2. Detail Topology in a Domain
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.
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 Jescia Chen, Adrian Farrel, and Eric
Wu for their valuable comments on this draft.
9. References
9.1. Normative References
Chen, et al. Expires July 10, 2021 [Page 10]
Internet-Draft H-Connect-Access January 2021
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://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,
<https://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,
<https://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,
<https://www.rfc-editor.org/info/rfc3630>.
9.2. Informative References
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
January 2009, <https://www.rfc-editor.org/info/rfc5392>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[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,
<https://www.rfc-editor.org/info/rfc7752>.
Chen, et al. Expires July 10, 2021 [Page 11]
Internet-Draft H-Connect-Access January 2021
Appendix A. Message Encoding
A.1. Extension to Existing Message
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:
o 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.
A.1.1. TLVs
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inter-Domain Link Sub-TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Chen, et al. Expires July 10, 2021 [Page 12]
Internet-Draft H-Connect-Access January 2021
of the router. For a router not running OSPF or IS-IS, the ID may be
the 32-bit ID of the router configured.
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)
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.
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/tTDB4) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cost |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length | IPv4/IPv6 Prefix (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.1.2. Sub-TLVs
The format of the Sub-TLV for a local IPv4/IPv6 address with mask
length is shown 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (stTBD1/stTBD2) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4/IPv6 Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask Length |
+-+-+-+-+-+-+-+-+
Chen, et al. Expires July 10, 2021 [Page 13]
Internet-Draft H-Connect-Access January 2021
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.2. New Message
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:
<AC Message> ::= <Common Header> <NRP>
<Connection-List> [<Access-List>]
where:
<Connection-List> ::= <Connection> [<Connection-List>]
<Connection> ::= [<Inter-Domain-Link> | <ABR>]
<Access-List> ::= <Access-Address> [<Access-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 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.2.1. CONNECTION and ACCESS Object
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:
Chen, et al. Expires July 10, 2021 [Page 14]
Internet-Draft H-Connect-Access January 2021
o CA Inter-Domain Link: CA Object-Type is 1.
o CA ABR: CA Object-Type is 2.
o CA Access IPv4 Prefix: CA Object-Type is 3.
o 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:
Object-Class = ocTBD1 (Connection and Access)
Object-Type = 1 (CA Inter-Domain 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 |
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inter-Domain Link TLVs |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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:
Object-Class = ocTBD1 (Connection and Access)
Object-Type = 2 (CA ABR)
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 TLVs |
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each of the Router-ID TLVs indicates an ABR in the domain. Flag W=1
indicates withdraw the ABRs. W=0 indicates new ABRs.
Chen, et al. Expires July 10, 2021 [Page 15]
Internet-Draft H-Connect-Access January 2021
The format of Access IPv4/IPv6 Prefix object body is as follows:
Object-Class = ocTBD1 (Connection and Access)
Object-Type = 3/4 (CA Access IPv4/IPv6 Prefix)
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 | Access IPv4/IPv6 Prefix TLVs |
+-+-+-+-+-+-+-+-+ +
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
Authors' Addresses
Huaimo Chen
Futurewei
Boston, MA
USA
EMail: Huaimo.chen@futurewei.com
Mehmet Toy
Verizon
,
USA
EMail: mehmet.toy@verizon.com
Xufeng Liu
Volta Networks
McLean, VA
USA
EMail: xufeng.liu.ietf@gmail.com
Chen, et al. Expires July 10, 2021 [Page 16]
Internet-Draft H-Connect-Access January 2021
Lei Liu
Fujitsu
USA
EMail: liulei.kddi@gmail.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 July 10, 2021 [Page 17]