draft-ietf-ccamp-gmpls-ason-routing-ospf-07.txt   draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt 
Network Working Group Dimitri Papadimitriou Network Working Group Dimitri Papadimitriou
Internet Draft (Alcatel-Lucent) Internet Draft (Alcatel-Lucent)
Category: Experimental Category: Experimental
Created: January 14, 2009 Created: April 7, 2009
Expires: July 14, 2009 Expires: October 7, 2009
OSPFv2 Routing Protocols Extensions for ASON Routing OSPFv2 Routing Protocols Extensions for ASON Routing
draft-ietf-ccamp-gmpls-ason-routing-ospf-07.txt draft-ietf-ccamp-gmpls-ason-routing-ospf-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with the
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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
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/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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.
Abstract Abstract
skipping to change at page 4, line 27 skipping to change at page 4, line 27
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 arranged in hierarchical levels such that any one RA may RAs are arranged in hierarchical levels such that any one RA may
contain multiple other RAs, and is wholly contained by a single RA. contain multiple other RAs, and is wholly contained by a single RA.
Thus, an RA may contain smaller RAs inter-connected by links. The Thus, an RA may contain smaller RAs inter-connected by links. The
limit of the subdivision results is an RA that contains just two limit of the subdivision results in an RA that contains just two
sub-networks interconnected by a single link. sub-networks interconnected by a single link.
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 routing areas. RA levels does not map to the hierarchy of OSPF routing areas.
Instead, successive hierarchical levels of RAs MUST be represented by Instead, successive hierarchical levels of RAs MUST be represented by
separate instances of the protocol. Thus, inter-level routing separate instances of the protocol. Thus, inter-level routing
information exchange (as described in Section 6) involves the export information exchange (as described in Section 6) involves the export
and import of routing information between protocol instances. and import of routing information between protocol instances.
An ASON RA may therefore be identified by the combination of its OSPF An ASON RA may therefore be identified by the combination of its OSPF
skipping to change at page 5, line 11 skipping to change at page 5, line 11
This extension takes the form of a network mask (a 32-bit number This extension takes the form of a network mask (a 32-bit number
indicating the range of IP addresses residing on a single IP indicating the range of IP addresses residing on a single IP
network/subnet). The set of local addresses are carried in an OSPFv2 network/subnet). The set of local addresses are carried in an OSPFv2
TE LSA node attribute TLV (a specific sub-TLV is defined per address TE LSA node attribute TLV (a specific sub-TLV is defined per address
family, i.e., IPv4 and IPv6, used as network-unique identifiers). family, i.e., IPv4 and IPv6, used as network-unique identifiers).
The proposed solution is to advertise the local address prefixes of The proposed solution is to advertise the local address prefixes of
a router as new sub-TLVs of the (OSPFv2 TE LSA) Node Attribute top a router as new sub-TLVs of the (OSPFv2 TE LSA) Node Attribute top
level TLV. This document defines the following sub-TLVs: level TLV. This document defines the following sub-TLVs:
- Node IPv4 Local Prefix sub-TLV: Type 3 - Length: variable - Node IPv4 Local Prefix sub-TLV: Type 3 (TBD) - Length: variable
- Node IPv6 Local Prefix sub-TLV: Type 4 - Length: variable - Node IPv6 Local Prefix sub-TLV: Type 4 (TBD) - Length: variable
3.1 Node IPv4 Local Prefix Sub-TLV 3.1 Node IPv4 Local Prefix Sub-TLV
The Type of the Node IPv4 Local Prefix sub-TLV is 3. The Value field The Type of the Node IPv4 Local Prefix sub-TLV is 3 (TBD). The Value
of this sub-TLV contains one or more local IPv4 prefixes. The Length field of this sub-TLV contains one or more local IPv4 prefixes. The
is set to 8 x n, where n is the number of local IPv4 prefixes Length is set to 8 x n, where n is the number of local IPv4 prefixes
included in the sub-TLV. included in the sub-TLV.
The Node IPv4 Local Prefix sub-TLV has the following format: The Node IPv4 Local Prefix sub-TLV has the following format:
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 (3) | Length (8 x n) | | Type (3 - TBD) | Length (8 x n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask 1 | | Network Mask 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address 1 | | IPv4 Address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Network Mask n | | Network Mask n |
skipping to change at page 5, line 48 skipping to change at page 5, line 48
| IPv4 Address n | | IPv4 Address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Network mask "i": A 32-bit number indicating the IPv4 address mask Network mask "i": A 32-bit number indicating the IPv4 address mask
for the advertised destination prefix "i". for the advertised destination prefix "i".
Each <Network mask, IPv4 Address> pair listed as part of this sub- Each <Network mask, IPv4 Address> pair listed as part of this sub-
TLV represents a reachable destination prefix hosted by the TLV represents a reachable destination prefix hosted by the
advertising Router ID. advertising Router ID.
The local addresses that can be learned from Opaque TE LSAs. That is, The local addresses that can be learned from Opaque TE LSAs (that is,
router address and TE interface addresses SHOULD NOT be advertised the router address and TE interface addresses) SHOULD NOT be
in the node IPv4 local prefix sub-TLV. advertised in the node IPv4 local prefix sub-TLV.
3.2 Node IPv6 Local Prefix Sub-TLV 3.2 Node IPv6 Local Prefix Sub-TLV
The Type of the Node IPv6 Local Prefix sub-TLV is 4. The Value field The Type of the Node IPv6 Local Prefix sub-TLV is 4 (TBD). The Value
of this sub-TLV contains one or more local IPv6 prefixes. IPv6 field of this sub-TLV contains one or more local IPv6 prefixes. IPv6
Prefix representation uses [RFC5340] Section A.4.1. Prefix representation uses [RFC5340] Section A.4.1.
The Node IPv6 Local Prefix sub-TLV has the following format: The Node IPv6 Local Prefix sub-TLV has the following format:
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 (4) | Length | | Type (4 - TBD) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) | | PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Address Prefix 1 | | IPv6 Address Prefix 1 |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | (0) | | PrefixLength | PrefixOptions | (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Address Prefix n | | IPv6 Address Prefix n |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length is set to Sum[n][4 + #32-bit words/4] where n is the Length is set to the sum over all of the local prefixes included in
number of local prefixes included in the sub-TLV. The encoding of the sub-TLV of (4 + (number of 32-bit words in the prefix)/4 ).
each prefix potentially using fewer than four 32-bit words is The encoding of each prefix potentially using fewer than four
described below. 32-bit words is described below.
PrefixLength: length in bits of the prefix. PrefixLength: length in bits of the prefix.
PrefixOptions: 8-bit field describing various capabilities PrefixOptions: 8-bit field describing various capabilities
associated with the prefix (see [RFC5340] Section A.4.2). associated with the prefix (see [RFC5340] Section A.4.2).
IPv6 Address Prefix "i": encoding of the prefix "i" itself as an IPv6 Address Prefix "i": encoding of the prefix "i" itself as an
even multiple of 32-bit words, padding with zero bits as even multiple of 32-bit words, padding with zero bits as
necessary. necessary.
skipping to change at page 7, line 30 skipping to change at page 7, line 30
The Interface Switching Capability Descriptor (ISCD) TE Attribute The Interface Switching Capability Descriptor (ISCD) TE Attribute
[RFC4202] identifies the ability of the TE link to support cross- [RFC4202] identifies the ability of the TE link to support cross-
connection to another link within the same layer, and the ability to connection to another link within the same layer, and the ability to
use a locally terminated connection that belongs to one layer as a use a locally terminated connection that belongs to one layer as a
data link for another layer (adaptation capability). However, the data link for another layer (adaptation capability). However, the
information associated to the ability to terminate connections information associated to the ability to terminate connections
within that layer (referred to as the termination capability) is within that layer (referred to as the termination capability) is
embedded with the adaptation capability. embedded with the adaptation capability.
For instance, a link between two optical cross-connects will contain For instance, a link between two optical cross-connects will contain
at least one ISCD attribute describing the LSC switching capability. at least one ISCD attribute describing the lambda switching capable
Whereas a link between an optical cross-connect and an IP/MPLS LSR (LSC) switching capability. Whereas a link between an optical cross-
will contain at least two ISCD attributes: one for the description connect and an IP/MPLS LSR will contain at least two ISCD attributes:
of the LSC termination capability and one for the PSC adaptation one for the description of the LSC termination capability and one for
capability. the packet switching capable (PSC) adaptation capability.
In OSPFv2, the Interface Switching Capability Descriptor (ISCD) is a In OSPFv2, the Interface Switching Capability Descriptor (ISCD) is a
sub-TLV (of type 15) of the top-level Link TLV (of type 2) [RFC4203]. sub-TLV (of type 15) of the top-level Link TLV (of type 2) [RFC4203].
The adaptation and termination capabilities are advertised using two The 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.
Per [RFC4202] and [RFC4203], an interface MAY have more than one Per [RFC4202] and [RFC4203], an interface MAY have more than one
ISCD sub-TLV. Hence, the corresponding advertisements should not ISCD sub-TLV. Hence, the corresponding advertisements should not
result in any compatibility issues. result in any compatibility issues.
skipping to change at page 9, line 33 skipping to change at page 9, line 33
brief, as unnumbered links have their ID defined on per Li bases, brief, as unnumbered links have their ID defined on per Li bases,
the remote Lj needs to be identified to scope the link remote ID to the remote Lj needs to be identified to scope the link remote ID to
the local Li. Therefore, the routing protocol MUST be able to the local Li. Therefore, the routing protocol MUST be able to
disambiguate the advertised TE links so that they can be associated disambiguate the advertised TE links so that they can be associated
with the correct TE Router-ID. with the correct TE Router-ID.
For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level
Link TLV is introduced that defines the local and the remote Link TLV is introduced that defines the local and the remote
TE Router-ID. TE Router-ID.
The Type of the Local and Remote TE Router-ID sub-TLV is 17, and its The Type of the Local and Remote TE Router-ID sub-TLV is 25 (TBD),
length is 8 octets. The Value field of this sub-TLV contains 4 and its length is 8 octets. The Value field of this sub-TLV contains
octets of Local TE Router Identifier followed by 4 octets of Remote 4 octets of Local TE Router Identifier followed by 4 octets of Remote
TE Router Identifier. The value of the Local and the Remote TE TE Router Identifier. The value of the Local and the Remote TE
Router Identifier SHOULD NOT be set to 0. Router 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 (17) | Length (8) | | Type (25 - TBD) | Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier | | Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote TE Router Identifier | | Remote TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV is only required to be included as part of the top This sub-TLV is only required to be included as part of the top
level Link TLV if the Router-ID is advertising on behalf of more level Link TLV if the Router-ID is advertising on behalf of more
than one TE Router-ID. In any other case, this sub-TLV SHOULD be than one TE Router-ID. In any other case, this sub-TLV SHOULD be
omitted except if operator plans to start of with 1 Li and omitted except if operator plans to start of with 1 Li and
skipping to change at page 10, line 23 skipping to change at page 10, line 23
defined in [RFC3630]. defined in [RFC3630].
5.3 Reachability Advertisement (Local TE Router ID sub-TLV) 5.3 Reachability Advertisement (Local TE Router ID sub-TLV)
When the Router-ID is advertised on behalf of multiple TE Router-IDs When the Router-ID is advertised on behalf of multiple TE Router-IDs
(Lis), the routing protocol MUST be able to associate the advertised (Lis), the routing protocol MUST be able to associate the advertised
reachability information with the correct TE Router-ID. reachability information with the correct TE Router-ID.
For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level For this purpose, a new sub-TLV of the (OSPFv2 TE LSA) top level
Node Attribute TLV is introduced. This TLV associates the local Node Attribute TLV is introduced. This TLV associates the local
prefixes (sub-TLV 3 and 4, see above) to a given TE Router-ID. prefixes (sub-TLV 3 and 4, TBD see above) to a given TE Router-ID.
The Type of the Local TE Router-ID sub-TLV is 5, and its Length is 4 The Type of the Local TE Router-ID sub-TLV is 5 (TBD), and its Length
octets. The value field of this sub-TLV contains the Local TE Router is 4 octets. The value field of this sub-TLV contains the Local TE
Identifier [RFC3630] encoded over 4 octets. Router Identifier [RFC3630] encoded over 4 octets.
The format of the Local TE Router-ID sub-TLV is: The format of the Local 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 (5) | Length (4) | | Type (5 - TBD) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local TE Router Identifier | | Local TE Router Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This sub-TLV is only required to be included be included as part of This sub-TLV is only required to be included be included as part of
the Node Attribute TLV if the Router-ID is advertising on behalf of the Node Attribute TLV if the Router-ID is advertising on behalf of
more than one TE Router-ID. In any other case, this sub-TLV SHOULD more than one TE Router-ID. In any other case, this sub-TLV SHOULD
be omitted. be omitted.
6. Routing Information Dissemination 6. Routing Information Dissemination
skipping to change at page 11, line 8 skipping to change at page 11, line 8
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. A RA may contain smaller RAs inter- representation of this partition. A RA may contain smaller RAs inter-
connected by links. The limit of the subdivision results is an RA connected by links. The limit of the subdivision results is an RA
that contains two sub-networks interconnected by a single link. ASON that contains two sub-networks interconnected by a single link. ASON
RA levels do not reflect routing protocol levels (such as OSPF RA levels do not reflect routing protocol levels (such as OSPF
areas). areas).
Successive hierarchical levels of RAs can be represented by separate Successive hierarchical levels of RAs can be represented by separate
instances of the protocol. instances of the protocol.
Routing controllers (RCs) supporting RAs disseminate informtation Routing controllers (RCs) supporting RAs disseminate information
downward and upward in this hierarchy. The vertical routing downward and upward in this hierarchy. The vertical routing
information dissemination mechanisms described in this section do not information dissemination mechanisms described in this section do not
introduce or imply a new OSPF routing area hierarchy. RCs supporting introduce or imply a new OSPF routing area hierarchy. RCs supporting
RAs at multiple levels are structured as separate OSPF instances with RAs at multiple levels are structured as separate OSPF instances with
routing information exchanges between levels described by import and routing information exchanges between levels described by import and
export rules operating between OSPF instances. export rules operating between OSPF instances.
The implication is that an RC that performs import/export of routing The implication is that an RC that performs import/export of routing
information as described in this document does not implement an Area information as described in this document does not implement an Area
Border Router (ABR) functionality. Border Router (ABR) functionality.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
information LSA [RFC4970]. The Length of this TLV is n x 4 octets. information LSA [RFC4970]. The Length of this TLV is n x 4 octets.
The Value field of this sub-TLV contains the list of Associated RA The Value field of this sub-TLV contains the list of Associated RA
IDs. Each Associated RA ID value is encoded following the OSPF area IDs. Each Associated RA ID value is encoded following the OSPF area
ID (32 bits) encoding rules defined in [RFC2328]. ID (32 bits) encoding rules defined in [RFC2328].
The format of the Downstream Associated RA ID TLV is: The format of the Downstream Associated RA ID 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 (TBD) | Length (4 x n) | | Type (7 - TBD) | Length (4 x n) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID 1 | | Associated RA ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// ... // // ... //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID n | | Associated RA ID n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 35 skipping to change at page 15, line 35
The Length of the Associated RA ID TLV is 4 octets. The Value field The Length of the Associated RA ID TLV is 4 octets. The Value field
of this sub-TLV contains the Associated RA ID. The Associated RA ID of this sub-TLV contains the Associated RA ID. The Associated RA ID
value is encoded following the OSPF area ID (32 bits) encoding rules value is encoded following the OSPF area ID (32 bits) encoding rules
defined in [RFC2328]. defined in [RFC2328].
The format of the Associated RA ID TLV is defined as follows: The format of the Associated RA ID TLV is defined as follows:
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 (TBD) | Length (4) | | Type (26 - TBD) | Length (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Associated RA ID | | Associated RA ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6.3.2 Processing 6.3.2 Processing
When fulfilling the rules detailed in Section 6.1 a given Opaque LSA When fulfilling the rules detailed in Section 6.1 a given Opaque LSA
is imported/exported downward or upward the routing hierarchy, the is imported/exported downward or upward the routing hierarchy, the
Associated RA ID TLV is added to the received opaque LSA list of TLVs Associated RA ID TLV is added to the received opaque LSA list of TLVs
such as to identify the area from which this routing information has such as to identify the area from which this routing information has
skipping to change at page 18, line 26 skipping to change at page 18, line 26
7. OSPFv2 Extensions 7. OSPFv2 Extensions
7.1 Compatibility 7.1 Compatibility
Extensions specified in this document are associated to the: Extensions specified in this document are associated to the:
1. Opaque Traffic Engineering LSA (Type 1) defined in [RFC3630]: 1. Opaque Traffic Engineering LSA (Type 1) defined in [RFC3630]:
- Router Address top level TLV (Type 1): - Router Address top level TLV (Type 1):
- Associated RA ID sub-TLV: optional sub-TLV for loop avoidance. - Associated RA ID sub-TLV (Type 26 TBD by IANA): optional
sub-TLV for loop avoidance.
- Link top level TLV (Type 2): - Link top level TLV (Type 2):
- Local and Remote TE Router-ID sub-TLV: optional sub-TLV for - Local and Remote TE Router-ID sub-TLV (Type 25 TBD by IANA):
scoping link attributes per TE Router-ID. optional sub-TLV for scoping link attributes per TE Router-ID.
- Associated RA ID sub-TLV: optional sub-TLV for loop avoidance. - Associated RA ID sub-TLV (Type 26 TBD by IANA): optional sub-
TLV for loop avoidance.
- Node Attribute top level TLV (Type TBD by IANA): 2. Node Attribute top level TLV (TBD by IANA [OSPF-NODE]):
- Node IPv4 Local Prefix sub-TLV: optional sub-TLV for IPv4 - Node IPv4 Local Prefix sub-TLV (Type 3 TBD by IANA): optional
reachability advertisement. sub-TLV for IPv4 reachability advertisement.
- Node IPv6 Local Prefix sub-TLV: optional sub-TLV for IPv6 - Node IPv6 Local Prefix sub-TLV (Type 4 TBD by IANA): optional
reachability advertisement. sub-TLV for IPv6 reachability advertisement.
- Local TE Router-ID sub-TLV: optional sub-TLV for scoping - Local TE Router-ID sub-TLV (Type 5 TBD by IANA): optional sub-
reachability per TE Router-ID. TLV for scoping reachability per TE Router-ID.
- Associated RA ID sub-TLV: optional sub-TLV for loop avoidance. - Associated RA ID sub-TLV (Type 26 by IANA): optional sub-TLV
for loop avoidance.
2. Opaque Router Information LSA (Type 4) defined in [RFC4970]: 3. Opaque Router Information LSA (Type 4) defined in [RFC4970]:
- Router Information Capability Descriptor TLV (Type 1). - Router Information Capability Descriptor TLV (Type 1).
- U bit in Capability Descriptor TLV (bit position TBD by IANA). - U bit in Capability Descriptor TLV (bit position 7 TBD by
IANA).
- D bit in Capability Descriptor TLV (bit position TBD by IANA). - D bit in Capability Descriptor TLV (bit position 8 TBD by
IANA).
- Router Downstream Associated RA ID TLV (Type - see Section - Downstream Associated RA ID TLV (Type 7 TBD by IANA).
9.2.2).
7.2 Scalability 7.2 Scalability
- 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 SHOULD 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 when allowing decreasing the amount of aggregation are RECOMMENDED when allowing decreasing the amount of
information imported/exported by a given RC without impacting information imported/exported by a given RC without impacting
consistency. consistency.
skipping to change at page 20, line 7 skipping to change at page 20, line 10
use of the HMAC algorithm in conjunction with the SHA family of use of the HMAC algorithm in conjunction with the SHA family of
cryptographic hash functions. cryptographic hash functions.
[RFC2154] adds i) digital signatures to authenticate OSPF LSA data, [RFC2154] adds i) digital signatures to authenticate OSPF LSA data,
ii) certification mechanism for distribution of routing information, ii) certification mechanism for distribution of routing information,
and iii) use a neighbor-to-neighbor authentication algorithm to and iii) use a neighbor-to-neighbor authentication algorithm to
protect local OSPFv2 protocol exchanges. protect local OSPFv2 protocol exchanges.
9. IANA Considerations 9. IANA Considerations
9.1 Sub-TLVs for the OSPF Opaque TE LSA 9.1 TLVs for the OSPF Opaque TE LSA
IANA manages a registry of sub-TLVs carried in traffic engineering IANA manages a registry of Top Level TLVs carried in the Opaque TE
TLVs in the Opaque TE LSA. This registry is found as the "Types for LSA. This is found as the "Open Shortest Path First (OSPF) Traffic
sub-TLVs of TE Link TLV" subregistry of the "Open Shortest Path First Engineering TLVs" registry.
(OSPF) Traffic Engineering TLVs" registry.
IANA is requested to make allocations from this registry for the 9.1.1. Sub-TLVs of the TE Link Top Level TLV
following new sub-TLVs:
- Associated RA ID sub-TLV: optional sub-TLV (see Section 6.3.1) IANA manages a subregistry for sub-TLVs carried in the TE Link top
level TLV. This is found as the "Types for sub-TLVs of TE Link TLV
(Value 2)" subregistry.
- Downstream Associated RA ID sub-TLV: optional sub-TLV (see IANA is requested to make allocations from this subregistry for the
Section 6.2) following new sub-TLVs. (Recommended values.)
- Local TE Router ID sub-TLV: optional sub-TLV (see Section 5.3) Value Sub-TLV Reference
------- ----------------------------- ---------
25 Local and Remote TE Router ID [This.ID]
26 Associated RA ID [This.ID]
- Local and Remote TE Router ID sub-TLV: optional sub-TLV (see The value for the Associated RA ID sub-TLV is requested to be
Section 5.2) consistent with the values for the same sub-TLV carried in other top
level TLVs (see Sections 9.1.2 and 9.1.3).
- Node IPv4 Local Prefix sub-TLV: optional sub-TLV (see Section 3.1) 9.1.2. Sub-TLVs of Router Address Top Level TLV
- Node IPv6 Local Prefix sub-TLV: optional sub-TLV (see Section 4.2) IANA is requested to create a subregistry to track sub-TLVs of the
Router Address Top Level TLV (type 1). The "Types for sub-TLVs of
Router Address TLV (Value 1)" subregistry should have the following
format and entries. (Recommended values.)
The additions to the sub-registry should read as follows: Range Registration Procedures Notes
----------- ----------------------- --------------------
0-32767 Standards Action
32768-32777 Experimental Use IANA does not assign
32778-65535 Standards Track RFC
Value Sub-TLV Reference Value Sub-TLV Reference
----------- -------------------------------------------- ---------- ------- ----------------------- ---------
TBD Associated RA ID [This.ID] 26 Associated RA ID [This.ID]
TBD Downstream Associated RA ID [This.ID]
TBD Local TE Router ID [This.ID] The value for the Associated RA ID sub-TLV is requested to be
TBD Local and Remote TE Router ID [This.ID] consistent with the values for the same sub-TLV carried in other top
TBD Node IPv4 Local Prefix [This.ID] level TLVs (see Sections 9.1.1 and 9.1.3).
TBD Node IPv6 Local Prefix [This.ID]
9.1.3. Node Attribute Top Level TLV and its Sub-TLVs
[OSPF-NODE] requests the allocaiton of a codepoint for the Node
Attribute TLV from the "Open Shortest Path First (OSPF) Traffic
Engineering TLVs" registry.
[OSPF-NODE] also requests the creation of a subregistry to track the
sub-TLVs of the Node Attribute TLV, and requests the allocation of
codepoints for sub-TLVs 1 and 2.
IANA is requested to make four further allocations from this
subregistry as follows. (Recommended values.)
Value Sub-TLV Reference
------- ---------------------- ---------
3 Node IPv4 Local Prefix [This.ID]
4 Node IPv6 Local Prefix [This.ID]
5 Local TE Router ID [This.ID]
26 Associated RA ID [This.ID]
The value for the Associated RA ID sub-TLV is requested to be
consistent with the values for the same sub-TLV carried in other top
level TLVs (see Sections 9.1.1 and 9.1.2).
9.2 OSPF RI LSA 9.2 OSPF RI LSA
9.2.1 RI Capability Bits 9.2.1 RI Capability Bits
IANA maintains the "Open Shortest Path First v2 (OSPFv2) Parameters" IANA maintains the "Open Shortest Path First v2 (OSPFv2) Parameters"
registry with a subregistry called "OSPF Router Informational registry with a subregistry called "OSPF Router Informational
Capability Bits". Capability Bits".
IANA is requested to allocate two new bits as follows: IANA is requested to allocate two new bits as follows. (Recommended
values.)
- U bit (see Section 6.2.1)
- D bit (see Section 6.2.2)
The registry entries should look as follows:
Bit Capabilities Reference Bit Capabilities Reference
-------- -------------------------------------- --------- -------- -------------------------------------- ---------
TBD Upward routing dissemination capable [This.ID] 7 Upward routing dissemination capable [This.ID]
TBD Downward routing dissemination capable [This.ID] 8 Downward routing dissemination capable [This.ID]
9.2.2 RI LSA TLVs 9.2.2 RI LSA TLVs
IANA maintains the "Open Shortest Path First v2 (OSPFv2) Parameters" IANA maintains the "Open Shortest Path First v2 (OSPFv2) Parameters"
registry with a subregistry called "OSPF Router Information (RI) registry with a subregistry called "OSPF Router Information (RI)
TLVs". TLVs". IANA is requested make an allocation from this subregistry as
follows. (Recommended values.)
An Experimental TLV is required as follows: Value Sub-TLV Reference
------- ---------------------- ---------
- Downstream Associated RA ID TLV (see Section 7.1). 7 Downstream Associated RA ID [This.ID]
The registry states that Experimental allocations are not tracked by
IANA. Therefore, this document assigns as follows:
Type Value Capabilities Reference
----------- -------------------------------------- ---------
32781 Downstream Associated RA ID [This.ID]
10. References 10. References
10.1 Normative References 10.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2154] Murphy, S., Badger, M. and B. Wellington, "OSPF with [RFC2154] Murphy, S., Badger, M. and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997. Digital Signatures", RFC 2154, June 1997.
skipping to change at page 23, line 18 skipping to change at page 23, line 45
Alcatel-Lucent Bell Alcatel-Lucent Bell
Copernicuslaan 50 Copernicuslaan 50
B-2018 Antwerpen B-2018 Antwerpen
Belgium Belgium
Phone: +32 3 2408491 Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel-lucent.be EMail: dimitri.papadimitriou@alcatel-lucent.be
Acknowledgements Acknowledgements
The authors would like to thank Dean Cheng, Acee Lindem, Pandian The authors would like to thank Dean Cheng, Acee Lindem, Pandian
Vijay, Alan Davey, Adrian Farrel, and Deborah Brungard for their Vijay, Alan Davey, Adrian Farrel, Deborah Brungard, and Ben Campbell
useful comments and suggestions. for their useful comments and suggestions.
Question 14 of Study Group 15 of the ITU-T provided useful and Question 14 of Study Group 15 of the ITU-T provided useful and
constructive input. constructive input.
Appendix 1: ASON Terminology Appendix 1: 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 purposes of Administrative domain: (see Recommendation G.805) for the purposes of
[G7715.1] an administrative domain represents the extent of resources [G7715.1] an administrative domain represents the extent of resources
skipping to change at page 27, line 11 skipping to change at page 27, line 11
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 RC. exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC.
The PC function is protocol dependent. The PC function is protocol dependent.
Full Copyright Statement Full Copyright Statement
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
 End of changes. 49 change blocks. 
103 lines changed or deleted 131 lines changed or added

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