< draft-ietf-ccamp-rfc5787bis-03.txt   draft-ietf-ccamp-rfc5787bis-04.txt >
INTERNET-DRAFT A. Malis, ed. INTERNET-DRAFT A. Malis, ed.
Intended Status: Proposed Standard Verizon Communications Obsoletes: 5787 (if approved) Verizon Communications
Expires: February 9, 2012 A. Lindem, ed. Updates: 5786 A. Lindem, ed.
Ericsson Intended Status: Proposed Standard Ericsson
D. Papadimitriou, ed. Expires: December 19, 2012 D. Papadimitriou, ed.
Alcatel-Lucent Alcatel-Lucent
August 8, 2011 June 19, 2012
Updates to ASON Routing for OSPFv2 Protocols (RFC 5787bis) ASON Routing for OSPFv2 Protocols
draft-ietf-ccamp-rfc5787bis-03.txt draft-ietf-ccamp-rfc5787bis-04.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 27 skipping to change at page 3, line 27
ASON routing, and an evaluation of existing GMPLS routing protocols ASON routing, and an evaluation of existing GMPLS routing protocols
are provided in other documents. This document defines extensions to are provided in other documents. This document defines extensions to
the OSPFv2 Link State Routing Protocol to meet the requirements for the OSPFv2 Link State Routing Protocol to meet the requirements for
routing in an ASON. routing in an ASON.
Note that this work is scoped to the requirements and evaluation Note that this work is scoped to the requirements and evaluation
expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations expressed in RFC 4258 and RFC 4652 and the ITU-T Recommendations
current when those documents were written. Future extensions of current when those documents were written. Future extensions of
revisions of this work may be necessary if the ITU-T Recommendations revisions of this work may be necessary if the ITU-T Recommendations
are revised or if new requirements are introduced into a revision of are revised or if new requirements are introduced into a revision of
RFC 4258. RFC 4258. This document obsoletes RFC 5787 and updates RFC 5786.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Conventions Used in This Document . . . . . . . . . . . . 6 1.1. Conventions Used in This Document . . . . . . . . . . . . 6
2. Routing Areas, OSPF Areas, and Protocol Instances . . . . . . 6 2. Routing Areas, OSPF Areas, and Protocol Instances . . . . . . 6
3. Terminology and Identification . . . . . . . . . . . . . . . . 7 3. Terminology and Identification . . . . . . . . . . . . . . . . 7
4. Reachability . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Reachability . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Link Attribute . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Link Attribute . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Local Adaptation . . . . . . . . . . . . . . . . . . . . . 8 5.1. Local Adaptation . . . . . . . . . . . . . . . . . . . . . 8
skipping to change at page 6, line 27 skipping to change at page 6, line 27
General ASON terminology is provided in Appendix A. ASON routing General ASON terminology is provided in Appendix A. ASON routing
terminology is described in Appendix B. terminology is described in Appendix B.
2. Routing Areas, OSPF Areas, and Protocol Instances 2. Routing Areas, OSPF Areas, and Protocol Instances
An ASON routing area (RA) represents a partition of the data plane, An ASON routing area (RA) represents a partition of the data plane,
and its identifier is used within the control plane as the and its identifier is used within the control plane as the
representation of this partition. representation of this partition.
RAs are hierarchically contained: a higher-level (parent) RA contains RAs are hierarchically contained: a higher-level (parent) RA contains
lower-level (child) RAs that in turn MAY also contain RAs, etc. lower-level (child) RAs that in turn MAY also contain RAs.
Thus, RAs contain RAs that recursively define successive hierarchical Thus, RAs contain RAs that recursively define successive hierarchical
RA levels. Routing information may be exchanged between levels of RA levels. Routing information may be exchanged between levels of
the RA hierarchy, i.e., Level N+1 and N, where Level N represents the the RA hierarchy, i.e., Level N+1 and N, where Level N represents the
RAs contained by Level N+1. The links connecting RAs may be viewed RAs contained by Level N+1. The links connecting RAs may be viewed
as external links (inter-RA links), and the links representing as external links (inter-RA links), and the links representing
connectivity within an RA may be viewed as internal links (intra-RA connectivity within an RA may be viewed as internal links (intra-RA
links). The external links to an RA at one level of the hierarchy links). The external links to an RA at one level of the hierarchy
may be internal links in the parent RA. Intra-RA links of a child RA may be internal links in the parent RA. Intra-RA links of a child RA
MAY be hidden from the parent RA's view. [RFC4258] MAY be hidden from the parent RA's view. [RFC4258]
skipping to change at page 7, line 14 skipping to change at page 7, line 14
reachability) which is used for ASON routing. reachability) which is used for ASON routing.
3. Terminology and Identification 3. Terminology and Identification
This section describes the mapping of key ASON entities to OSPF This section describes the mapping of key ASON entities to OSPF
entities. Appendix A contains a complete glossary of ASON routing entities. Appendix A contains a complete glossary of ASON routing
terminology. terminology.
There are three categories of identifiers used for ASON routing There are three categories of identifiers used for ASON routing
(G7715.1): transport plane names, control plane identifiers for (G7715.1): transport plane names, control plane identifiers for
components, and SCN addresses. This section discusses the mapping components, and Signaling Communications Network (SCN) addresses.
between ASON routing identifiers and corresponding identifiers This section discusses the mapping between ASON routing identifiers
defined for GMPLS routing, and how these support the physical (or and corresponding identifiers defined for GMPLS routing, and how
logical) separation of transport plane entities and control plane these support the physical (or logical) separation of transport plane
components. GMPLS supports this separation of identifiers and entities and control plane components. GMPLS supports this
planes. separation of identifiers and planes.
In the context of OSPF Traffic Engineering (TE), an ASON transport In the context of OSPF Traffic Engineering (TE), an ASON transport
node corresponds to a unique OSPF TE node. An OSPF TE node is node corresponds to a unique OSPF TE node. An OSPF TE node is
uniquely identified by the TE Router Address TLV [RFC3630]. In this uniquely identified by the TE Router Address TLV [RFC3630]. In this
document, this TE Router Address is referred to as the TE Router ID, document, this TE Router Address is referred to as the TE Router ID,
which is in the ASON transport plane name space. The TE Router ID which is in the ASON SCN name space. The TE Router ID
should not be confused with the OSPF Router ID which uniquely should not be confused with the OSPF Router ID which uniquely
identifies an OSPF router within an OSPF routing domain [RFC2328] and identifies an OSPF router within an OSPF routing domain [RFC2328] and
is in a name space for control plane components. is in a name space for control plane components.
Note: The Router Address top-level TLV definition, processing, and The Router Address top-level TLV definition, processing, and
usage are unchanged from [RFC3630]. This TLV specifies a stable OSPF usage are largely unchanged from [RFC3630]. This TLV specifies a stable
TE node IP address, i.e., the IP address is always reachable when OSPF TE node IP address, i.e., the IP address is always reachable when
there is IP connectivity to the associated OSPF TE node. there is IP connectivity to the associated OSPF TE node. However, in
the context of the OSPF ASON operation, the TE Router ID is an
identifier within the ASON SCN.
ASON defines a Routing Controller (RC) as an entity that handles ASON defines a Routing Controller (RC) as an entity that handles
(abstract) information needed for routing and the routing information (abstract) information needed for routing and the routing information
exchange with peering RCs by operating on the Routing Database (RDB). exchange with peering RCs by operating on the Routing Database (RDB).
ASON defines a Protocol Controller (PC) as an entity that handles ASON defines a Protocol Controller (PC) as an entity that handles
protocol-specific message exchanges according to the reference point protocol-specific message exchanges according to the reference point
over which the information is exchanged (e.g., E-NNI, I-NNI), and over which the information is exchanged (e.g., E-NNI, I-NNI), and
internal exchanges with the Routing Controller (RC) [RFC4258]. In internal exchanges with the Routing Controller (RC) [RFC4258]. In
this document, an OSPF router advertising ASON TE topology this document, an OSPF router advertising ASON TE topology
information will perform both the functions of the RC and PC. Each information will perform both the functions of the RC and PC. The
OSPF routing domain comprises the control plane and each
OSPF router is uniquely identified by its OSPF Router ID [RFC2328]. OSPF router is uniquely identified by its OSPF Router ID [RFC2328].
4. Reachability 4. Reachability
Reachability in ASON refers to the set of endpoints reachable in the In ASON, reachability refers to the set of endpoints reachable in the
transport plane by a node or the reachable endpoints of a level N. transport plane by an associated ASON transport node.
Reachable entities are identified in the transport plane name space Reachable entities are identified in the ASON SCN name space.
(ASON SNPP name space). In order to advertise blocks of reachable
In order to advertise blocks of reachable
address prefixes, a summarization mechanism is introduced that is address prefixes, a summarization mechanism is introduced that is
based on the techniques described in [RFC5786]. For ASON reachability based on the techniques described in [RFC5786]. For ASON reachability
advertisement, blocks of reachable address prefixes are advertised advertisement, blocks of reachable address prefixes are advertised
together with the associated data plane node. The data plane node is together with the associated transport plane node. The transport
identified in the control plane by its TE Router ID, as discussed in plane node is identified in OSPF TE LSAs by its TE Router ID,
section 6. as discussed in section 6.
In order to support ASON reachability advertisement, the Node In order to support ASON reachability advertisement, the Node
Attribute TLV defined in [RFC5786] is used to advertise the Attribute TLV defined in [RFC5786] is used to advertise the
combination of a TE Router ID and its set of associated reachable combination of a TE Router ID and its set of associated reachable
address prefixes. The Node Attribute TLV can contain the following address prefixes. The Node Attribute TLV can contain the following
sub-TLVs: sub-TLVs:
- TE Router ID sub-TLV: Length: 4; Defined in Section 6.2 - TE Router ID sub-TLV: Length: 4; Defined in Section 6.2
- Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786] - Node IPv4 Local Address sub-TLV: Length: variable; [RFC5786]
- Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786] - Node IPv6 Local Address sub-TLV: Length: variable; [RFC5786]
A router may support multiple transport nodes as discussed in section A router may support multiple transport nodes as discussed in section
6, and, as a result, may be required to advertise reachability (ASON 6, and, as a result, may be required to advertise reachability
SNPPs) separately for each transport node. As a consequence, it MUST separately for each transport node. As a consequence, it MUST
be possible for the router to originate more than one TE LSA be possible for the router to originate more than one TE LSA
containing the Node Attribute TLV when used for ASON reachability containing the Node Attribute TLV when used for ASON reachability
advertisement. advertisement.
Hence, the Node Attribute TLV [RFC5786] advertisement rules must be Hence, the Node Attribute TLV [RFC5786] advertisement rules are
relaxed for ASON. A Node Attribute TLV MAY appear in more than one TE relaxed. A Node Attribute TLV MAY appear in more than one TE
LSA originated by the RC when the RC is advertising reachability LSA originated by the RC when the RC is advertising reachability
information for a different transport node identified by the Local TE information for a different transport node identified by the Local TE
Router Sub-TLV (refer to section 6.1). Router Sub-TLV (refer to section 6.1).
5. Link Attribute 5. Link Attribute
With the exception of local adaptation (described below), the mapping With the exception of local adaptation (described below), the mapping
of link attributes and characteristics to OSPF TE Link TLV Sub-TLVs of link attributes and characteristics to OSPF TE Link TLV Sub-TLVs
is unchanged [RFC4652]. OSPF TE Link TLV Sub-TLVs are described in is unchanged [RFC4652]. OSPF TE Link TLV Sub-TLVs are described in
[RFC3630] and [RFC4203]. Advertisement of this information SHOULD be [RFC3630] and [RFC4203]. Advertisement of this information SHOULD be
skipping to change at page 9, line 31 skipping to change at page 9, line 31
adaptation and termination capabilities are advertised using two adaptation and termination capabilities are advertised using two
separate ISCD sub-TLVs within the same top-level Link TLV. separate ISCD sub-TLVs within the same top-level Link TLV.
An interface MAY have more than one ISCD sub-TLV, [RFC4202] and An interface MAY have more than one ISCD sub-TLV, [RFC4202] and
[RFC4203]. Hence, the corresponding advertisements should not result [RFC4203]. Hence, the corresponding advertisements should not result
in any compatibility issues. in any compatibility issues.
5.2. Bandwidth Accounting 5.2. Bandwidth Accounting
GMPLS routing defines an Interface Switching Capability Descriptor GMPLS routing defines an Interface Switching Capability Descriptor
(ISCD) that provides, among other things, the available (ISCD) that provides, among other things, the quantities of the
(maximum/minimum) bandwidth per priority available for Label Switched maximum/minimum available bandwidth per priority for Label Switched
Path (LSPs). One or more ISCD sub-TLVs can be associated with an Path (LSPs). One or more ISCD sub-TLVs can be associated with an
interface, [RFC4202] and [RFC4203]. This information, combined with interface, [RFC4202] and [RFC4203]. This information, combined with
the Unreserved Bandwidth Link TLV sub-TLV [RFC3630], provides the the Unreserved Bandwidth Link TLV sub-TLV [RFC3630], provides the
basis for bandwidth accounting. basis for bandwidth accounting.
In the ASON context, additional information may be included when the In the ASON context, additional information may be included when the
representation and information in the other advertised fields are not representation and information in the other advertised fields are not
sufficient for a specific technology, e.g., SDH. The definition of sufficient for a specific technology, e.g., SDH. The definition of
technology-specific information elements is beyond the scope of this technology-specific information elements is beyond the scope of this
document. Some technologies will not require additional information document. Some technologies will not require additional information
beyond what is already defined in [RFC3630], [RFC4202], and beyond what is already defined in [RFC3630], [RFC4202], and
[RFC4203]. [RFC4203].
6. Routing Information Scope 6. Routing Information Scope
For ASON routing, the control plane component routing adjacency For ASON routing, the control plane component routing adjacency
topology (i.e., the associated Protocol Controller (PC) connectivity) topology (i.e., the associated Protocol Controller (PC) connectivity)
and the transport topology are NOT assumed to be congruent [RFC4258]. and the transport topology are not assumed to be congruent [RFC4258].
Hence, a single OSPF router (i.e., the PC) MUST be able to advertise Hence, a single OSPF router (i.e., the PC) MUST be able to advertise
on behalf of multiple transport layer nodes. The OSPF routers are on behalf of multiple transport layer nodes. The OSPF routers are
identified by OSPF Router ID and the transport nodes are identified identified by OSPF Router ID and the transport nodes are identified
by TE Router ID. by TE Router ID.
The Router Address TLV [RFC3630] is used to advertise the TE Router The Router Address TLV [RFC3630] is used to advertise the TE Router
ID associated with the advertising Routing Controller. TE Router IDs ID associated with the advertising Routing Controller (RC). TE Router IDs
for additional transport nodes are advertised through specification for additional transport nodes are advertised through specification
of the Local TE Router Identifier in the Local and Remote TE Router of the Local TE Router Identifier in the Local and Remote TE Router
TE sub-TLV and the Local TE Router Identifier sub-TLV described in TE sub-TLV and the Local TE Router Identifier sub-TLV described in
the sections below. These Local TE Router Identifiers are typically the sections below. These Local TE Router Identifiers are typically
used as the local endpoints for TE Label Switched Paths (LSPs) used as the local endpoints for TE Label Switched Paths (LSPs)
terminating on the associated transport node. terminating on the associated transport node.
It MAY be feasible for multiple OSPF Routers to advertise TE The use of multiple OSPF Routers to advertise TE information for the
information for the same transport node. However, this is not same transport node is not considered a required use case and is not
considered a required use case and is not discussed further. discussed further in this document.
6.1. Link Advertisement (Local and Remote TE Router ID Sub-TLV) 6.1. Link Advertisement (Local and Remote TE Router ID Sub-TLV)
An OSPF router advertising on behalf of multiple transport nodes will When an OSPF Router advertises on behalf of multiple transport nodes,
require additional information to distinguish the link endpoints the link end points cannot be automatically assigned to a single
amongst the subsumed transport nodes. In order to unambiguously transport node associated with the advertising router. In this case,
specify the transport topology, the local and remote transport nodes the local and remote transport nodes MUST be identified by TE router
MUST be identified by TE router ID. ID to unambiguously specify the transport topology.
For this purpose, a new sub-TLV of the OSPFv2 TE LSA top-level Link For this purpose, a new sub-TLV of the OSPFv2 TE LSA top-level Link
TLV is introduced that defines the Local and Remote TE Router ID. TLV is introduced that defines the Local and Remote TE Router ID.
The Type field of the Local and Remote TE Router ID sub-TLV is The Type field of the Local and Remote TE Router ID sub-TLV is
assigned the value 26 (see Section 10). The Length field takes the assigned the value TBDx (see Section 10). The Length field takes the
value 8. The Value field of this sub-TLV contains 4 octets of the value 8. The Value field of this sub-TLV contains 4 octets of the
Local TE Router Identifier followed by 4 octets of the Remote TE Local TE Router Identifier followed by 4 octets of the Remote TE
Router Identifier. The value of the Local and Remote TE Router Router Identifier. The value of the Local and Remote TE Router
Identifier SHOULD NOT be set to 0. Identifier SHOULD NOT be set to 0.
The format of the Local and Remote TE Router ID sub-TLV is: The format of the Local and Remote TE Router ID sub-TLV is:
0 1 2 3 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 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 (26) | Length (8) | | Type (TBDx) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier | | Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Router Identifier | | Remote TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV MUST be included as a sub-TLV of the top-level Link TLV This sub-TLV MUST be included as a sub-TLV of the top-level Link TLV
if the OSPF router is advertising on behalf of one or more transport if the OSPF router is advertising on behalf of one or more transport
nodes having TE Router IDs different from the TE Router ID advertised nodes having TE Router IDs different from the TE Router ID advertised
in the Router Address TLV. Therefore, it MUST be included if the in the Router Address TLV. For consistency, this sub-TLV MUST be
OSPF router is advertising on behalf of multiple transport nodes. included when OSPF is used for the advertisement of ASON information
as described herein. If it is not included in a Link TLV or a value
of 0 is specified for the Local or Remote TE Router Identifier, the
Link TLV will not be used for transport plane path computation.
Additionally, the condition SHOULD be logged for possible action by
the network operator.
Note: The Link ID sub-TLV identifies the other end of the link (i.e., Note: The Link ID sub-TLV identifies the other end of the link (i.e.,
Router ID of the neighbor for point-to-point links) [RFC3630]. When Router ID of the neighbor for point-to-point links) [RFC3630]. When
the Local and Remote TE Router ID Sub-TLV is present, it MUST be used the Local and Remote TE Router ID Sub-TLV is present, it MUST be used
to identify local and remote transport node endpoints for the link to identify local and remote transport node endpoints for the link
and the Link-ID sub-TLV MUST be ignored. The Local and Remote ID sub- and the Link-ID sub-TLV MUST be ignored. In fact, when the Local
TLV, if specified, MUST only be specified once. and Remote ID sub-TLV is specified, the Link-ID sub-TLV MAY be omitted.
The Local and Remote ID sub-TLV, if specified, MUST only be specified once.
If specified more than once, instances preceding the first will be ignored and
condition SHOULD be logged for possible action by the network operator.
6.2. Reachability Advertisement (Local TE Router ID sub-TLV) 6.2. Reachability Advertisement (Local TE Router ID sub-TLV)
When an OSPF router is advertising on behalf of multiple transport When an OSPF router is advertising on behalf of multiple transport
nodes, the routing protocol MUST be able to associate the advertised nodes, the routing protocol MUST be able to associate the advertised
reachability information with the correct transport node. reachability information with the correct transport node.
For this purpose, a new sub-TLV of the OSPFv2 TE LSA top-level Node For this purpose, a new sub-TLV of the OSPFv2 TE LSA top-level Node
Attribute TLV is introduced. This TLV associates the local prefixes Attribute TLV is introduced. This TLV associates the local prefixes
(see above) to a given transport node identified by TE Router ID. (see above) to a given transport node identified by TE Router ID.
skipping to change at page 11, line 44 skipping to change at page 11, line 52
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 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 (5) | Length (4) | | Type (5) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier | | Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV MUST be included as a sub-TLV of the top-level Node This sub-TLV MUST be included as a sub-TLV of the top-level Node
Attribute TLV if the OSPF router is advertising on behalf of one or Attribute TLV if the OSPF router is advertising on behalf of one or
more transport nodes having TE Router IDs different from the TE more transport nodes having TE Router IDs different from the TE
Router ID advertised in the Router Address TLV. Therefore, it MUST Router ID advertised in the Router Address TLV. For consistency,
be included if the OSPF router is advertising on behalf of multiple this sub-TLV MUST be included when OSPF is used for the advertisement
transport nodes. of ASON information as described herein. If it is not included in a
Node Attribute TLV or a value of 0 is specified for the Local TE
Router Identifier, the Note Attribute TLV will not be used for
determining ASON SCN reachability. Additionally, the condition
SHOULD be logged for possible action by the network operator.
7. Routing Information Dissemination 7. Routing Information Dissemination
An ASON routing area (RA) represents a partition of the data plane, An ASON routing area (RA) represents a partition of the data plane,
and its identifier is used within the control plane as the and its identifier is used within the control plane as the
representation of this partition. An RA may contain smaller RAs representation of this partition. An RA may contain smaller RAs
inter-connected by links. ASON RA levels do not map directly to OSPF inter-connected by links. ASON RA levels do not map directly to OSPF
areas. Rather, hierarchical levels of RAs are represented by separate areas. Rather, hierarchical levels of RAs are represented by separate
OSPF protocol instances. OSPF protocol instances. However, it is useful to align the RA
identifiers and area ID in order to facilitate isolation of RAs as
described in Section 11.1.
Routing controllers (RCs) supporting multiple RAs disseminate Routing controllers (RCs) supporting multiple RAs disseminate
information downward and upward in this ASON hierarchy. The vertical information downward and upward in this ASON hierarchy. The vertical
routing information dissemination mechanisms described in this routing information dissemination mechanisms described in this
section do not introduce or imply hierarchical OSPF areas. RCs section do not introduce or imply hierarchical OSPF areas. RCs
supporting RAs at multiple levels are structured as separate OSPF supporting RAs at multiple levels are structured as separate OSPF
instances with routing information exchange between levels described instances with routing information exchange between levels described
by import and export rules between these instances. The functionality by import and export rules between these instances. The functionality
described herein does not pertain to OSPF areas or OSPF Area Border described herein does not pertain to OSPF areas or OSPF Area Border
Router (ABR) functionality. Router (ABR) functionality.
skipping to change at page 12, line 38 skipping to change at page 12, line 40
LSAs are area-scoped opaque LSAs with opaque type 1 [RFC3630]. The LSAs are area-scoped opaque LSAs with opaque type 1 [RFC3630]. The
information that MAY be exchanged between adjacent levels includes information that MAY be exchanged between adjacent levels includes
the Router Address, Link, and Node Attribute top-level TLVs. the Router Address, Link, and Node Attribute top-level TLVs.
The imported/exported routing information content MAY be transformed, The imported/exported routing information content MAY be transformed,
e.g., filtered or aggregated, as long as the resulting routing e.g., filtered or aggregated, as long as the resulting routing
information is consistent. In particular, when more than one RC is information is consistent. In particular, when more than one RC is
bound to adjacent levels and both are allowed to import/export bound to adjacent levels and both are allowed to import/export
routing information, it is expected that these transformations are routing information, it is expected that these transformations are
performed in a consistent manner. Definition of these policy-based performed in a consistent manner. Definition of these policy-based
mechanisms is outside the scope of this document. mechanisms are outside the scope of this document.
In practice, and in order to avoid scalability and processing In practice, and in order to avoid scalability and processing
overhead, routing information imported/exported downward/upward in overhead, routing information imported/exported downward/upward in
the hierarchy is expected to include reachability information (see the hierarchy is expected to include reachability information (see
Section 4) and, upon strict policy control, link topology Section 4) and, upon strict policy control, link topology
information. information.
7.2 Loop Prevention 7.2 Loop Prevention
When more than one RC is bound to an adjacent level of the ASON When more than one RC is bound to an adjacent level of the ASON
skipping to change at page 13, line 14 skipping to change at page 13, line 14
information upward or downward into an upper or lower level RA in the information upward or downward into an upper or lower level RA in the
ASON hierarchy. For example, without loop prevention mechanisms, this ASON hierarchy. For example, without loop prevention mechanisms, this
could happen when the RC advertising routing information downward in could happen when the RC advertising routing information downward in
the hierarchy is not the same one that advertises routing information the hierarchy is not the same one that advertises routing information
upward in the hierarchy. upward in the hierarchy.
7.2.1 Inter-RA Export Upward/Downward Sub-TLVs 7.2.1 Inter-RA Export Upward/Downward Sub-TLVs
The Inter-RA Export Sub-TLVs can be used to prevent the re- The Inter-RA Export Sub-TLVs can be used to prevent the re-
advertisement of OSPF TE routing information into an RA which advertisement of OSPF TE routing information into an RA which
previously advertised that information. The type value 28 (see previously advertised that information. The type value TBDz (see
Section 10) will indicate that the associated routing information has Section 10) will indicate that the associated routing information has
been exported downward. The type value 27 (see Section 10) will been exported downward. The type value TBDy (see Section 10) will
indicate that the associated routing information has been exported indicate that the associated routing information has been exported
upward. While it is not required for routing information exported upward. While it is not required for routing information exported
downward, both Sub-TLVs will include the Routing Area (RA) ID from downward, both Sub-TLVs will include the Routing Area (RA) ID from
the which the routing information was exported. This RA is not which the routing information was exported. This RA is not
necessarily the RA originating the routing information but RA from necessarily the RA originating the routing information but RA from
which the information was immediately exported. which the information was immediately exported.
These additional Sub-TLVs MAY be included in TE LSAs that include any These additional Sub-TLVs MAY be included in TE LSAs that include any
of the following top-level TLVs: of the following top-level TLVs:
- Router Address top-level TLV - Router Address top-level TLV
- Link top-level TLV - Link top-level TLV
- Node Attribute top-level TLV - Node Attribute top-level TLV
The Type field of the Inter-RA Export Upward and Inter-RA Export The Type field of the Inter-RA Export Upward and Inter-RA Export
Downward sub-TLVs are respectively assigned the values 27 and 28 (see Downward sub-TLVs are respectively assigned the values TBDy and TBDz
Section 10). The Length field in these Sub-TLVs takes the value 4. (see Section 10). The Length field in these Sub-TLVs takes the
The Value field in these sub-TLVs contains the associated RA ID. The value 4. The Value field in these sub-TLVs contains the associated
RA ID value must be a unique identifier for the RA within the ASON RA ID. The RA ID value must be a unique identifier for the RA within
routing domain. the ASON routing domain.
The format of the Inter-RA Export Upward and Inter-RA Export Downward The format of the Inter-RA Export Upward and Inter-RA Export Downward
Sub-TLVs is graphically depicted below: Sub-TLVs is graphically depicted below:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Upward/Downward Type (27/28) | Length (4) | | Upward/Downward Type | Length (4) |
| (TBDy/TBDz) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID | | Associated RA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.2.2 Inter-RA Export Upward/Downward Sub-TLV Processing 7.2.2 Inter-RA Export Upward/Downward Sub-TLV Processing
TE LSAs MAY be imported or exported downward or upward in the ASON TE LSAs MAY be imported or exported downward or upward in the ASON
routing hierarchy. The direction and advertising RA ID are advertised routing hierarchy. The direction and advertising RA ID are advertised
in an Inter-RA Export Upward/Downward Sub-TLV. They MUST be retained in an Inter-RA Export Upward/Downward Sub-TLV. They MUST be retained
and advertised in the receiving RA with the associated routing and advertised in the receiving RA with the associated routing
skipping to change at page 14, line 34 skipping to change at page 14, line 34
information. This additional checking is required for routing information. This additional checking is required for routing
information exported downward since a single RA at level N+1 may information exported downward since a single RA at level N+1 may
contain multiple RAs at level N in the ASON routing hierarchy. In contain multiple RAs at level N in the ASON routing hierarchy. In
order words, routing information MUST NOT be exported downward into order words, routing information MUST NOT be exported downward into
the RA from which it was received. the RA from which it was received.
8. OSPFv2 Scalability 8. OSPFv2 Scalability
The extensions described herein are only applicable to ASON routing The extensions described herein are only applicable to ASON routing
domains and it is not expected that the attendant reachability (see domains and it is not expected that the attendant reachability (see
Section 4) and link information will ever be mixed with global or Section 4) and link information will ever be combined with global
local IP routing information. If there were ever a requirement for a Internet or Layer 3 Virtual Private Network (VPN) routing. If there
given RC to participate in both domains, separate OSPFv2 instances were ever a requirement for a given RC to participate in both domains,
would be utilized. However, in a multi-level ASON hierarchy, the separate OSPFv2 instances would be utilized. However, in a
potential volume of information could be quite large and the multi-level ASON hierarchy, the potential volume of information could
recommendations in this section SHOULD be followed by RCs be quite large and the recommendations in this section MUST be
implementing this specification. followed by RCs implementing this specification.
- Routing information exchange upward/downward in the hierarchy - Routing information exchange upward/downward in the hierarchy
between adjacent RAs SHOULD, by default, be limited to reachability between adjacent RAs MUST, by default, be limited to reachability
information. In addition, several transformations such as prefix information. In addition, several transformations such as prefix
aggregation are RECOMMENDED to reduce the amount of information aggregation are RECOMMENDED to reduce the amount of information
imported/exported by a given RC when such transformations will not imported/exported by a given RC when such transformations will not
impact consistency. impact consistency.
- Routing information exchange upward/downward in the ASON hierarchy - Routing information exchange upward/downward in the ASON hierarchy
involving TE attributes MUST be under strict policy control. involving TE attributes MUST be under strict policy control.
Pacing and min/max thresholds for triggered updates are strongly Pacing and min/max thresholds for triggered updates are strongly
RECOMMENDED. RECOMMENDED.
skipping to change at page 15, line 32 skipping to change at page 15, line 32
packets by making use of the HMAC algorithm in conjunction with the packets by making use of the HMAC algorithm in conjunction with the
SHA family of cryptographic hash functions. SHA family of cryptographic hash functions.
If a stronger authentication were believed to be required, then the If a stronger authentication were believed to be required, then the
use of a full digital signature [RFC2154] would be an approach that use of a full digital signature [RFC2154] would be an approach that
should be seriously considered. Use of full digital signatures would should be seriously considered. Use of full digital signatures would
enable precise authentication of the OSPF router originating each enable precise authentication of the OSPF router originating each
OSPF link-state advertisement, and thereby provide much stronger OSPF link-state advertisement, and thereby provide much stronger
integrity protection for the OSPF routing domain. integrity protection for the OSPF routing domain.
RCs implementing export/import of ASON routing information between
RAs MUST also include policy control of both the maximum amount of
information advertised between RAs and the maximum rate at which
it is advertised. This is to isolate the consequences of an RC
being compromised to the RAs to which that subverted RC is attached.
10. IANA Considerations 10. IANA Considerations
This document is classified as Standards Track. It defines new sub- This document is classified as Standards Track. It defines new sub-
TLVs for inclusion in OSPF TE LSAs. According to the assignment TLVs for inclusion in OSPF TE LSAs. According to the assignment
policies for the registries of code points for these sub-TLVs, values policies for the registries of code points for these sub-TLVs, values
must be assigned by IANA [RFC3630]. must be assigned by IANA [RFC3630].
This draft requests early allocation of IANA code points in This draft requests early allocation of IANA code points in
accordance with [RFC4020]. [NOTE TO RFC Editor: this paragraph and accordance with [RFC4020]. [NOTE TO RFC Editor: this paragraph and
the RFC 4020 reference can be removed during RFC editing]. the RFC 4020 reference can be removed during RFC editing].
The following subsections summarize the required sub-TLVs. The following subsections summarize the required sub-TLVs.
10.1. Sub-TLVs of the Link TLV 10.1. Sub-TLVs of the Link TLV
This document defines the following sub-TLVs of the Link TLV This document defines the following sub-TLVs of the Link TLV
advertised in the OSPF TE LSA: advertised in the OSPF TE LSA:
- Local and Remote TE Router ID sub-TLV (26) - Local and Remote TE Router ID sub-TLV (TBDx)
- Inter-RA Export Upward sub-TLV (27) - Inter-RA Export Upward sub-TLV (TBDy)
- Inter-RA Export Downward sub-TLV (28) - Inter-RA Export Downward sub-TLV (TBDz)
Codepoints for these Sub-TLVs should be allocated from the "Types for Codepoints for these Sub-TLVs should be allocated from the "Types for
sub-TLVs of TE Link TLV (Value 2)" registry standards action range (0 sub-TLVs of TE Link TLV (Value 2)" registry standards action range (0
- 32767) [RFC3630]. - 32767) [RFC3630].
Note that the same values for the Inter-RA Export Upward sub-TLV and Note that the same values for the Inter-RA Export Upward sub-TLV and
the Inter-RA Export Downward Sub-TLV MUST be used when they appear in the Inter-RA Export Downward Sub-TLV MUST be used when they appear in
the Link TLV, Node Attribute TLV, and Router Address TLV. the Link TLV, Node Attribute TLV, and Router Address TLV.
10.2. Sub-TLVs of the Node Attribute TLV 10.2. Sub-TLVs of the Node Attribute TLV
This document defines the following sub-TLVs of the Node Attribute This document defines the following sub-TLVs of the Node Attribute
TLV advertised in the OSPF TE LSA: TLV advertised in the OSPF TE LSA:
- Local TE Router ID sub-TLV (5) - Local TE Router ID sub-TLV (5)
- Inter-RA Export Upward sub-TLV (27) - Inter-RA Export Upward sub-TLV (TDBy)
- Inter-RA Export Downward sub-TLV (28) - Inter-RA Export Downward sub-TLV (TBDz)
Codepoints for these Sub-TLVs should be assigned from the "Types for Codepoints for these Sub-TLVs should be assigned from the "Types for
sub-TLVs of TE Node Attribute TLV (Value 5)" registry standards sub-TLVs of TE Node Attribute TLV (Value 5)" registry standards
action range (0 - 32767) [RFC5786]. action range (0 - 32767) [RFC5786].
Note that the same values for the Inter-RA Export Upward sub-TLV and Note that the same values for the Inter-RA Export Upward sub-TLV and
the Inter-RA Export Downward Sub-TLV MUST be used when they appear in the Inter-RA Export Downward Sub-TLV MUST be used when they appear in
the Link TLV, Node Attribute TLV, and Router Address TLV. the Link TLV, Node Attribute TLV, and Router Address TLV.
10.3. Sub-TLVs of the Router Address TLV 10.3. Sub-TLVs of the Router Address TLV
skipping to change at page 17, line 5 skipping to change at page 17, line 5
RFCs. RFCs.
o Types in the range 32778-65535 are not to be assigned at this o Types in the range 32778-65535 are not to be assigned at this
time. Before any assignments can be made in this range, there time. Before any assignments can be made in this range, there
MUST be a Standards Track RFC that specifies IANA MUST be a Standards Track RFC that specifies IANA
Considerations that covers the range being assigned. Considerations that covers the range being assigned.
This document defines the following sub-TLVs for inclusion in the This document defines the following sub-TLVs for inclusion in the
Router Address TLV: Router Address TLV:
- Inter-RA Export Upward sub-TLV (27) - Inter-RA Export Upward sub-TLV (TBDy)
- Inter-RA Export Downward sub-TLV (28) - Inter-RA Export Downward sub-TLV (TBDz)
Codepoints for these Sub-TLVs should be allocated from the "Types for Codepoints for these Sub-TLVs should be allocated from the "Types for
sub-TLVs of Router Address TLV (Value 1)" registry standards action sub-TLVs of Router Address TLV (Value 1)" registry standards action
range (0 - 32767). range (0 - 32767).
Note that the same values for the Inter-RA Export Upward sub-TLV and Note that the same values for the Inter-RA Export Upward sub-TLV and
the Inter-RA Export Downward Sub-TLV MUST be used when they appear in the Inter-RA Export Downward Sub-TLV MUST be used when they appear in
the Link TLV, Node Attribute TLV, and Router Address TLV. the Link TLV, Node Attribute TLV, and Router Address TLV.
11. Management Considerations 11. Management Considerations
skipping to change at page 18, line 23 skipping to change at page 18, line 23
| |communications between RCs,| transport and | routing | | |communications between RCs,| transport and | routing |
| |and the subsequent recovery|control plane. | protocol. | | |and the subsequent recovery|control plane. | protocol. |
| |from the failure condition | | | | |from the failure condition | | |
| | MUST NOT disrupt call in | | | | | MUST NOT disrupt call in | | |
| | progress. | | | | | progress. | | |
+----------+---------------------------+---------------+-------------+ +----------+---------------------------+---------------+-------------+
| 3.1 (2) |Multiple Hierarchical Level| Yes | Sections 2 | | 3.1 (2) |Multiple Hierarchical Level| Yes | Sections 2 |
| | of ASON Routing Areas | | and 3 | | | of ASON Routing Areas | | and 3 |
| | (RAs). | | | | | (RAs). | | |
+----------+---------------------------+---------------+-------------+ +----------+---------------------------+---------------+-------------+
| 3.1 (3) | Prior to establishing | Yes when RA |Section 11.1 | | 3.1 (3) | Prior to establishing | Yes, when RA |Section 11.1 |
| | communications, RCs MUST | maps to OSPF | | | | communications, RCs MUST | maps to OSPF | |
| |verify that they are bound | Area ID. | | | |verify that they are bound | Area ID. | |
| | to the same parent RA. | | | | | to the same parent RA. | Otherwise, | |
| | | out of scope. | |
+----------+---------------------------+---------------+-------------+ +----------+---------------------------+---------------+-------------+
| 3.1 (4) | The RC ID MUST be unique | Yes |RFC 2328 and | | 3.1 (4) | The RC ID MUST be unique | Yes |RFC 2328 and |
| | within its containing RA. | | Section 3. | | | within its containing RA. | | Section 3. |
+----------+---------------------------+---------------+-------------+ +----------+---------------------------+---------------+-------------+
| 3.1 (5) |Each RA within a carrier's |Yes - although | Sections 2, | | 3.1 (5) |Each RA within a carrier's |Yes - although | Sections 2, |
| | network SHALL be uniquely | uniqueness is | 3, and 11.1 | | | network SHALL be uniquely | uniqueness is | 3, and 11.1 |
| |identifiable. RA IDs MAY be|the operator's | | | |identifiable. RA IDs MAY be|the operator's | |
| |associated with a transport|responsibility.| | | |associated with a transport|responsibility.| |
| | plane name space, whereas | | | | | plane name space, whereas | | |
| |RC IDs are associated with | | | | |RC IDs are associated with | | |
skipping to change at page 20, line 16 skipping to change at page 20, line 16
| | routing function and an | | 3, and 7 | | | routing function and an | | 3, and 7 |
| | instance of a Level N+1 | | | | | instance of a Level N+1 | | |
| | routing function in the | | | | | routing function in the | | |
| | same system. | | | | | same system. | | |
+----------+---------------------------+---------------+-------------+ +----------+---------------------------+---------------+-------------+
| 3.2 (15) | The Level N routing | Not described | N/A | | 3.2 (15) | The Level N routing | Not described | N/A |
| | function is on a separate | but possible. | | | | function is on a separate | but possible. | |
| | system the Level N+1 | | | | | system the Level N+1 | | |
| | routing function. | | | | | routing function. | | |
+----------+---------------------------+---------------+-------------+ +----------+---------------------------+---------------+-------------+
| 3.3 (16) |The RC MUST support static | Yes - | Sections 2 | | 3.3 (16) |The RC MUST support static | The automation| Sections 2 |
| | (i.e., operator assisted) | automation |and 3. Config| | | (i.e., operator assisted) | requirement is|and 3. Config|
| | and MAY support automated |requirement is | is product | | | and MAY support automated | ambiguous. | is product |
| | configuration of the | ambiguous. | specific. | | | configuration of the | OSPF supports | specific. |
| |information describing its | | | | |information describing its | auto-discovery| Refer to |
| |relationship to its parent | | | | |relationship to its parent | of neighbors | RFC 2328 for|
| | and its child within the | | | | | and its child within the | and topology. | OSPF auto- |
| | hierarchical structure | | | | | hierarchical structure | Default and | discovery. |
| | (including RA ID and RC | | | | | (including RA ID and RC | automatically | |
| | ID). | | | | | ID). | configured | |
| | | polices are | |
| | | out of scope. | |
+----------+---------------------------+---------------+-------------+ +----------+---------------------------+---------------+-------------+
| 3.3 (17) |The RC MUST support static |Yes - when OSPF|RFC 2328 and | | 3.3 (17) |The RC MUST support static |Yes - when OSPF|RFC 2328 and |
| | (i.e., operator assisted) |area maps to RA|Section 11.1 | | | (i.e., operator assisted) |area maps to RA|Section 11.1 |
| | and MAY support automated | discovery is | | | | and MAY support automated | discovery is | |
| | configuration of the | automatic. | | | | configuration of the | automatic. | |
| |information describing its | | | | |information describing its | | |
| | associated adjacencies to | | | | | associated adjacencies to | | |
| | other RCs within an RA. | | | | | other RCs within an RA. | | |
+----------+---------------------------+---------------+-------------+ +----------+---------------------------+---------------+-------------+
| 3.3 (18) |The routing protocol SHOULD| Yes | RFC 2328 | | 3.3 (18) |The routing protocol SHOULD| Yes | RFC 2328 |
skipping to change at page 25, line 15 skipping to change at page 25, line 15
[G.805] ITU-T Rec. G.805, "Generic Functional Architecture of [G.805] ITU-T Rec. G.805, "Generic Functional Architecture of
Transport Networks)", March 2000. Transport Networks)", March 2000.
[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
Automatically Switched Optical Network (ASON)," June Automatically Switched Optical Network (ASON)," June
2006 (and Amendments 1 (March 2008) and 2 (Sept. 2010)). 2006 (and Amendments 1 (March 2008) and 2 (Sept. 2010)).
14. Acknowledgements 14. Acknowledgements
The editors would like to thank Lyndon Ong, Remi Theillaud, Stephen The editors would like to thank Lyndon Ong, Remi Theillaud, Stephen
Shew, Jonathan Sadler, Deborah Brungard, and Lou Berger for their Shew, Jonathan Sadler, Deborah Brungard, Lou Berger, and Adrian
useful comments and suggestions. Farrel for their useful comments and suggestions.
14.1 RFC 5787 Acknowledgements
The author would like to thank Dean Cheng, Acee Lindem, Pandian
Vijay, Alan Davey, Adrian Farrel, Deborah Brungard, and Ben Campbell
for their useful comments and suggestions.
Lisa Dusseault and Jari Arkko provided useful comments during IESG
review.
Question 14 of Study Group 15 of the ITU-T provided useful and
constructive input.
Appendix A. ASON Terminology Appendix A. ASON Terminology
This document makes use of the following terms: This document makes use of the following terms:
Administrative domain: (See Recommendation [G.805].) For the Administrative domain: (See Recommendation [G.805].) For the
purposes of [G7715.1], an administrative domain represents the purposes of [G7715.1], an administrative domain represents the
extent of resources that belong to a single player such as a extent of resources that belong to a single player such as a
network operator, a service provider, or an end-user. network operator, a service provider, or an end-user.
Administrative domains of different players do not overlap amongst Administrative domains of different players do not overlap amongst
 End of changes. 41 change blocks. 
95 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/