< draft-ietf-ccamp-rfc5787bis-04.txt   draft-ietf-ccamp-rfc5787bis-05.txt >
INTERNET-DRAFT A. Malis, ed. INTERNET-DRAFT A. Malis, ed.
Obsoletes: 5787 (if approved) Verizon Communications Obsoletes: 5787 (if approved) Verizon Communications
Updates: 5786 A. Lindem, ed. Updates: 5786 A. Lindem, ed.
Intended Status: Proposed Standard Ericsson Intended Status: Proposed Standard Ericsson
Expires: December 19, 2012 D. Papadimitriou, ed. Expires: January 21, 2013 D. Papadimitriou, ed.
Alcatel-Lucent Alcatel-Lucent
June 19, 2012 July 20, 2012
ASON Routing for OSPFv2 Protocols ASON Routing for OSPFv2 Protocols
draft-ietf-ccamp-rfc5787bis-04.txt draft-ietf-ccamp-rfc5787bis-05.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 3, line 35 skipping to change at page 3, line 35
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. This document obsoletes RFC 5787 and updates RFC 5786. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Link Attribute . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Link Attribute . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Local Adaptation . . . . . . . . . . . . . . . . . . . . . 8 5.1. Local Adaptation . . . . . . . . . . . . . . . . . . . . . 9
5.2. Bandwidth Accounting . . . . . . . . . . . . . . . . . . . 9 5.2. Bandwidth Accounting . . . . . . . . . . . . . . . . . . . 9
6. Routing Information Scope . . . . . . . . . . . . . . . . . . 9 6. Routing Information Scope . . . . . . . . . . . . . . . . . . 10
6.1. Link Advertisement (Local and Remote TE Router ID 6.1. Link Advertisement (Local and Remote TE Router ID
Sub-TLV) . . . . . . . . . . . . . . . . . . . . . . . . . 10 Sub-TLV) . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. Reachability Advertisement (Local TE Router ID sub-TLV) . 11 6.2. Reachability Advertisement (Local TE Router ID sub-TLV) . 11
7. Routing Information Dissemination . . . . . . . . . . . . . . 12 7. Routing Information Dissemination . . . . . . . . . . . . . . 12
7.1 Import/Export Rules . . . . . . . . . . . . . . . . . . . . 12 7.1 Import/Export Rules . . . . . . . . . . . . . . . . . . . . 12
7.2 Loop Prevention . . . . . . . . . . . . . . . . . . . . . . 12 7.2 Loop Prevention . . . . . . . . . . . . . . . . . . . . . . 13
7.2.1 Inter-RA Export Upward/Downward Sub-TLVs . . . . . . . 13 7.2.1 Inter-RA Export Upward/Downward Sub-TLVs . . . . . . . 13
7.2.2 Inter-RA Export Upward/Downward Sub-TLV Processing . . 14 7.2.2 Inter-RA Export Upward/Downward Sub-TLV Processing . . 14
8. OSPFv2 Scalability . . . . . . . . . . . . . . . . . . . . . . 14 8. OSPFv2 Scalability . . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10.1. Sub-TLVs of the Link TLV . . . . . . . . . . . . . . . . 15 10.1. Sub-TLVs of the Link TLV . . . . . . . . . . . . . . . . 16
10.2. Sub-TLVs of the Node Attribute TLV . . . . . . . . . . . 16 10.2. Sub-TLVs of the Node Attribute TLV . . . . . . . . . . . 16
10.3. Sub-TLVs of the Router Address TLV . . . . . . . . . . . 16 10.3. Sub-TLVs of the Router Address TLV . . . . . . . . . . . 17
11. Management Considerations . . . . . . . . . . . . . . . . . 17 11. Management Considerations . . . . . . . . . . . . . . . . . 17
11.1. Routing Area (RA) Isolation . . . . . . . . . . . . . . . 17 11.1. Routing Area (RA) Isolation . . . . . . . . . . . . . . . 18
11.2 Routing Area (RA) Topology/Configuration Changes . . . . . 17 11.2 Routing Area (RA) Topology/Configuration Changes . . . . . 18
12. Comparison to Requirements in RFC 4258 . . . . . . . . . . . 17 12. Comparison to Requirements in RFC 4258 . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
13.1. Normative References . . . . . . . . . . . . . . . . . . 23 13.1. Normative References . . . . . . . . . . . . . . . . . . 24
13.2. Informative References . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . 25
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. ASON Terminology . . . . . . . . . . . . . . . . . . 26 14.1 RFC 5787 Acknowledgements . . . . . . . . . . . . . . . . . 26
Appendix B. ASON Routing Terminology . . . . . . . . . . . . . . 27 Appendix A. ASON Terminology . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix B. ASON Routing Terminology . . . . . . . . . . . . . . 28
Appendix C. Changes from RFC 5787 . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945] The Generalized Multiprotocol Label Switching (GMPLS) [RFC3945]
protocol suite is designed to provide a control plane for a range of protocol suite is designed to provide a control plane for a range of
network technologies including optical networks such as time division network technologies including optical networks such as time division
multiplexing (TDM) networks including SONET/SDH and Optical Transport multiplexing (TDM) networks including SONET/SDH and Optical Transport
Networks (OTNs), and lambda switching optical networks. Networks (OTNs), and lambda switching optical networks.
The ITU-T defines the architecture of the Automatically Switched The ITU-T defines the architecture of the Automatically Switched
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. lower-level (child) RAs that in turn MAY also contain RAs. Thus, RAs
Thus, RAs contain RAs that recursively define successive hierarchical contain RAs that recursively define successive hierarchical RA
RA levels. Routing information may be exchanged between levels of levels. Routing information may be exchanged between levels of the
the RA hierarchy, i.e., Level N+1 and N, where Level N represents the RA hierarchy, i.e., Level N+1 and N, where Level N represents the RAs
RAs contained by Level N+1. The links connecting RAs may be viewed contained by Level N+1. The links connecting RAs may be viewed as
as external links (inter-RA links), and the links representing 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]
An ASON RA can be mapped to an OSPF area, but the hierarchy of ASON An ASON RA can be mapped to an OSPF area, but the hierarchy of ASON
RA levels does not map to the hierarchy of OSPF areas. Instead, RA levels does not map to the hierarchy of OSPF areas. Instead,
successive hierarchical levels of RAs MUST be represented by separate successive hierarchical levels of RAs MUST be represented by separate
instances of the protocol. Thus, inter-level routing information instances of the protocol. Thus, inter-level routing information
exchange (as described in Section 7) involves the export and import exchange (as described in Section 7) involves the export and import
skipping to change at page 7, line 25 skipping to change at page 7, line 25
This section discusses the mapping between ASON routing identifiers This section discusses the mapping between ASON routing identifiers
and corresponding identifiers defined for GMPLS routing, and how and corresponding identifiers defined for GMPLS routing, and how
these support the physical (or logical) separation of transport plane these support the physical (or logical) separation of transport plane
entities and control plane components. GMPLS supports this entities and control plane components. GMPLS supports this
separation of identifiers and 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 SCN name space. The TE Router ID which is in the ASON SCN name space. The TE Router ID should not be
should not be confused with the OSPF Router ID which uniquely confused with the OSPF Router ID which uniquely identifies an OSPF
identifies an OSPF router within an OSPF routing domain [RFC2328] and router within an OSPF routing domain [RFC2328] and is in a name space
is in a name space for control plane components. for control plane components.
The Router Address top-level TLV definition, processing, and The Router Address top-level TLV definition, processing, and usage
usage are largely unchanged from [RFC3630]. This TLV specifies a stable are largely unchanged from [RFC3630]. This TLV specifies a stable
OSPF 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
there is IP connectivity to the associated OSPF TE node. However, in when there is IP connectivity to the associated OSPF TE node.
the context of the OSPF ASON operation, the TE Router ID is an However, in the context of the OSPF ASON operation, the TE Router ID
identifier within the ASON SCN. 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. The information will perform both the functions of the RC and PC. The
OSPF routing domain comprises the control plane and each OSPF routing domain comprises the control plane and each OSPF router
OSPF router is uniquely identified by its OSPF Router ID [RFC2328]. is uniquely identified by its OSPF Router ID [RFC2328].
4. Reachability 4. Reachability
In ASON, reachability refers to the set of endpoints reachable in the In ASON, reachability refers to the set of endpoints reachable in the
transport plane by an associated ASON transport node. transport plane by an associated ASON transport node. Reachable
Reachable entities are identified in the ASON SCN name space. entities are identified in the ASON SCN name space.
In order to advertise blocks of reachable In order to advertise blocks of reachable address prefixes, a
address prefixes, a summarization mechanism is introduced that is summarization mechanism is introduced that is based on the techniques
based on the techniques described in [RFC5786]. For ASON reachability described in [RFC5786]. For ASON reachability advertisement, blocks
advertisement, blocks of reachable address prefixes are advertised of reachable address prefixes are advertised together with the
together with the associated transport plane node. The transport associated transport plane node. The transport plane node is
plane node is identified in OSPF TE LSAs by its TE Router ID, identified in OSPF TE LSAs by its TE Router ID, as discussed in
as discussed in section 6. 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 6, and, as a result, may be required to advertise reachability
separately for each transport node. As a consequence, it MUST separately for each transport node. As a consequence, it MUST be
be possible for the router to originate more than one TE LSA possible for the router to originate more than one TE LSA containing
containing the Node Attribute TLV when used for ASON reachability the Node Attribute TLV when used for ASON reachability advertisement.
advertisement.
Hence, the Node Attribute TLV [RFC5786] advertisement rules are Hence, the Node Attribute TLV [RFC5786] advertisement rules are
relaxed. A Node Attribute TLV MAY appear in more than one TE relaxed. A Node Attribute TLV MAY appear in more than one TE LSA
LSA originated by the RC when the RC is advertising reachability 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
supported on a per-layer basis, i.e., one TE LSA per unique switching supported on a per-layer basis, i.e., one TE LSA per unique switching
skipping to change at page 9, line 44 skipping to change at page 10, line 4
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 (RC). TE Router IDs ID associated with the advertising Routing Controller (RC). TE Router
for additional transport nodes are advertised through specification IDs for additional transport nodes are advertised through
of the Local TE Router Identifier in the Local and Remote TE Router specification of the Local TE Router Identifier in the Local and
TE sub-TLV and the Local TE Router Identifier sub-TLV described in Remote TE Router TE sub-TLV and the Local TE Router Identifier sub-
the sections below. These Local TE Router Identifiers are typically TLV described in the sections below. These Local TE Router
used as the local endpoints for TE Label Switched Paths (LSPs) Identifiers are typically used as the local endpoints for TE Label
terminating on the associated transport node. Switched Paths (LSPs) terminating on the associated transport node.
The use of multiple OSPF Routers to advertise TE information for the The use of multiple OSPF Routers to advertise TE information for the
same transport node is not considered a required use case and is not same transport node is not considered a required use case and is not
discussed further in this document. 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)
When an OSPF Router advertises on behalf of multiple transport nodes, When an OSPF Router advertises on behalf of multiple transport nodes,
the link end points cannot be automatically assigned to a single the link end points cannot be automatically assigned to a single
transport node associated with the advertising router. In this case, transport node associated with the advertising router. In this case,
skipping to change at page 10, line 44 skipping to change at page 11, line 10
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 (TBDx) | 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. For consistency, this sub-TLV MUST be in the Router Address TLV. For consistency, this sub-TLV MUST be
skipping to change at page 11, line 18 skipping to change at page 11, line 32
as described herein. If it is not included in a Link TLV or a value 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 of 0 is specified for the Local or Remote TE Router Identifier, the
Link TLV will not be used for transport plane path computation. Link TLV will not be used for transport plane path computation.
Additionally, the condition SHOULD be logged for possible action by Additionally, the condition SHOULD be logged for possible action by
the network operator. 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. In fact, when the Local and the Link-ID sub-TLV MUST be ignored. In fact, when the Local and
and Remote ID sub-TLV is specified, the Link-ID sub-TLV MAY be omitted. 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. The Local and Remote ID sub-TLV, if specified, MUST only be specified
If specified more than once, instances preceding the first will be ignored and once. If specified more than once, instances preceding the first will
condition SHOULD be logged for possible action by the network operator. 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 13, line 33 skipping to change at page 14, line 8
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 TBDy and TBDz Downward sub-TLVs are respectively assigned the values TBDy and TBDz
(see Section 10). The Length field in these Sub-TLVs takes the (see Section 10). The Length field in these Sub-TLVs takes the value
value 4. The Value field in these sub-TLVs contains the associated 4. The Value field in these sub-TLVs contains the associated RA ID.
RA ID. The RA ID value must be a unique identifier for the RA within The RA ID value must be a unique identifier for the RA within the
the ASON routing domain. 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 | Length (4) | | Upward/Downward Type | Length (4) |
| (TBDy/TBDz) | | | (TBDy/TBDz) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 14, line 36 skipping to change at page 15, line 11
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 combined with global Section 4) and link information will ever be combined with global
Internet or Layer 3 Virtual Private Network (VPN) routing. If there Internet or Layer 3 Virtual Private Network (VPN) routing. If there
were ever a requirement for a given RC to participate in both domains, were ever a requirement for a given RC to participate in both
separate OSPFv2 instances would be utilized. However, in a domains, separate OSPFv2 instances would be utilized. However, in a
multi-level ASON hierarchy, the potential volume of information could multi-level ASON hierarchy, the potential volume of information could
be quite large and the recommendations in this section MUST be be quite large and the recommendations in this section MUST be
followed by RCs 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 MUST, 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.
skipping to change at page 15, line 34 skipping to change at page 16, line 9
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 RCs implementing export/import of ASON routing information between
RAs MUST also include policy control of both the maximum amount of RAs MUST also include policy control of both the maximum amount of
information advertised between RAs and the maximum rate at which information advertised between RAs and the maximum rate at which it
it is advertised. This is to isolate the consequences of an RC is advertised. This is to isolate the consequences of an RC being
being compromised to the RAs to which that subverted RC is attached. 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
skipping to change at page 16, line 4 skipping to change at page 16, line 34
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 (TBDx) - Local and Remote TE Router ID sub-TLV (TBDx)
- Inter-RA Export Upward sub-TLV (TBDy) - Inter-RA Export Upward sub-TLV (TBDy)
- Inter-RA Export Downward sub-TLV (TBDz) - 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 (TDBy) - Inter-RA Export Upward sub-TLV (TBDy)
- Inter-RA Export Downward sub-TLV (TBDz) - 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.
skipping to change at page 28, line 28 skipping to change at page 29, line 28
Link Resource Manager (LRM): supplies all the relevant component and Link Resource Manager (LRM): supplies all the relevant component and
TE link information to the RC. It informs the RC about any state TE link information to the RC. It informs the RC about any state
changes of the link resources it controls. changes of the link resources it controls.
Protocol Controller (PC): handles protocol-specific message exchanges Protocol Controller (PC): handles protocol-specific message exchanges
according to the reference point over which the information is according to the reference point over which the information is
exchanged (e.g., E-NNI, I-NNI), and internal exchanges with the exchanged (e.g., E-NNI, I-NNI), and internal exchanges with the
RC. The PC function is protocol dependent. RC. The PC function is protocol dependent.
Appendix C. Changes from RFC 5787
This document contains the following changes from RFC 5787:
1. This document will be on the Standards Track rather than
Experimental, and reflects experience gained from RFC 5787
implementation and interoperability testing. This also required
changes to the IANA Considerations.
2. There is a new Section 3 on Terminology and Identification to
describe the mapping of key ASON entities to OSPF entities.
3. Sections were reorganized to explain terminology before defining
prefix extensions.
4. There is a new Section 11, Management Considerations, which
describes how existing OSPF mechanisms address ASON requirements
on Routing Area changes.
5. There is a new Section 12 which compares the document to the
requirements in RFC 4258.
6. The prefix format was changed to reference RFC 5786 rather than
defining a separate format, and The Node Attribute TLV in RFC 5786
has been updated as a result.
7. Routing Information Advertisements were simplified from RFC 5787.
8. Review comments from ITU-T SG15 and the IESG were incorporated.
Authors' Addresses Authors' Addresses
Andrew G. Malis Andrew G. Malis
Verizon Communications Verizon Communications
117 West St. 60 Sylvan Rd.
Waltham MA 02451 USA Waltham MA 02451 USA
EMail: andrew.g.malis@verizon.com EMail: andrew.g.malis@verizon.com
Acee Lindem Acee Lindem
Ericsson Ericsson
102 Carric Bend Court 102 Carric Bend Court
Cary, NC 27519 Cary, NC 27519
EMail: acee.lindem@ericsson.com EMail: acee.lindem@ericsson.com
 End of changes. 30 change blocks. 
78 lines changed or deleted 112 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/