draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt   draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt 
CCAMP Working Group John Drake (Boeing) CCAMP Working Group Chris Hopps (Cisco)
Internet Draft Chris Hopps (Cisco) Internet Draft Lyndon Ong (Ciena)
Category: Informational Lyndon Ong (Ciena) Category: Informational Dimitri Papadimitriou (Alcatel)
Dimitri Papadimitriou (Alcatel) Jonathan Sadler (Tellabs)
Expiration Date: October 2005 Jonathan Sadler (Tellabs) Expiration Date: January 2006 Stephen Shew (Nortel)
Stephen Shew (Nortel)
Dave Ward (Cisco) Dave Ward (Cisco)
April 2005 July 2005
Evaluation of existing Routing Protocols Evaluation of existing Routing Protocols
against ASON routing requirements against ASON Routing Requirements
draft-ietf-ccamp-gmpls-ason-routing-eval-00.txt draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which I become aware will be disclosed, in accordance have been or will be disclosed, and any of which he or she becomes
with RFC 3668. aware will be disclosed, in accordance with Section 6 of 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 and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
The Generalized MPLS (GMPLS) suite of protocols has been defined to The Generalized MPLS (GMPLS) suite of protocols has been defined to
control different switching technologies as well as different control different switching technologies as well as different
applications. These include support for requesting TDM connections applications. These include support for requesting TDM connections
including SONET/SDH and Optical Transport Networks (OTNs). including SONET/SDH and Optical Transport Networks (OTNs).
J.Drake et al. - Expires October 2005 1 C.Hopps et al. - Expires January 2006 1
This document provides an evaluation of the IETF Routing Protocols This document provides an evaluation of the IETF Routing Protocols
against the routing requirements for an Automatically Switched against the routing requirements for an Automatically Switched
Optical Network (ASON) as defined by ITU-T. Optical Network (ASON) as defined by ITU-T.
1. Contributors 1. Contributors
This document is the result of the CCAMP Working Group ASON Routing This document is the result of the CCAMP Working Group ASON Routing
Solution design team joint effort. Solution design team joint effort.
Dimitri Papadimitriou (Alcatel, Team Leader and Editor)
EMail: dimitri.papadimitriou@alcatel.be
Chris Hopps (Cisco)
EMail: chopps@rawdofmt.org
Lyndon Ong (Ciena Corporation)
EMail: lyong@ciena.com
Jonathan Sadler (Tellabs)
EMail: jonathan.sadler@tellabs.com
Stephen Shew (Nortel Networks)
EMail: sdshew@nortelnetworks.com
Dave Ward (Cisco)
EMail: dward@cisco.com
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Introduction 3. Introduction
There are certain capabilities that are needed to support the ITU-T There are certain capabilities that are needed to support the ITU-T
Automatically Switched Optical Network (ASON) control plane Automatically Switched Optical Network (ASON) control plane
skipping to change at line 92 skipping to change at line 104
However, [ASON-RR] does not address GMPLS routing protocol However, [ASON-RR] does not address GMPLS routing protocol
applicability or capabilities. This document evaluates the IETF applicability or capabilities. This document evaluates the IETF
Routing Protocols against the requirements identified in [ASON-RR]. Routing Protocols against the requirements identified in [ASON-RR].
The result of this evaluation is detailed in Section 5. Close The result of this evaluation is detailed in Section 5. Close
examination of applicability scenarios and the result of the examination of applicability scenarios and the result of the
evaluation of these scenarios are provided in Section 6. evaluation of these scenarios are provided in Section 6.
ASON (Routing) terminology sections are provided in Appendix 1 and 2. ASON (Routing) terminology sections are provided in Appendix 1 and 2.
C.Hopps et al. - Expires January 2006 2
4. Requirements - Overview 4. Requirements - Overview
The following functionality is expected from GMPLS routing protocol The following functionality is expected from GMPLS routing protocol
to instantiate the ASON hierarchical routing architecture realization to instantiate the ASON hierarchical routing architecture realization
(see [G.7715] and [G.7715.1]): (see [G.7715] and [G.7715.1]):
- Routing Areas (RAs) shall be uniquely identifiable within a - Routing Areas (RAs) shall be uniquely identifiable within a
carrier's network, each having a unique RA Identifier (RA ID) carrier's network, each having a unique RA Identifier (RA ID)
within the carrier's network. within the carrier's network.
- Within a RA (one level), the routing protocol shall support - Within a RA (one level), the routing protocol shall support
dissemination of hierarchical routing information (including dissemination of hierarchical routing information (including
summarized routing information for other levels) in support of an summarized routing information for other levels) in support of an
J.Drake et al. - Expires October 2005 2
architecture of multiple hierarchical levels of RAs; the number of architecture of multiple hierarchical levels of RAs; the number of
hierarchical RA levels to be supported by a routing protocol is hierarchical RA levels to be supported by a routing protocol is
implementation specific. implementation specific.
- The routing protocol shall support routing information based on a - The routing protocol shall support routing information based on a
common set of information elements as defined in [G.7715] and common set of information elements as defined in [G.7715] and
[G.7715.1], divided between attributes pertaining to links and [G.7715.1], divided between attributes pertaining to links and
abstract nodes (each representing either a sub-network or simply a abstract nodes (each representing either a sub-network or simply a
node). [G.7715] recognizes that the manner in which the routing node). [G.7715] recognizes that the manner in which the routing
information is represented and exchanged will vary with the information is represented and exchanged will vary with the
routing protocol used. routing protocol used.
skipping to change at line 145 skipping to change at line 157
Reachability information may be advertised either as a set of UNI Reachability information may be advertised either as a set of UNI
Transport Resource address prefixes, or a set of associated Transport Resource address prefixes, or a set of associated
Subnetwork Point Pool (SNPP) link IDs/SNPP link ID prefixes, assigned Subnetwork Point Pool (SNPP) link IDs/SNPP link ID prefixes, assigned
and selected consistently in their applicability scope. The formats and selected consistently in their applicability scope. The formats
of the control plane identifiers in a protocol realization are of the control plane identifiers in a protocol realization are
implementation specific. Use of a routing protocol within a RA should implementation specific. Use of a routing protocol within a RA should
not restrict the choice of routing protocols for use in other RAs not restrict the choice of routing protocols for use in other RAs
(child or parent). (child or parent).
C.Hopps et al. - Expires January 2006 3
As ASON does not restrict the control plane architecture choice used, As ASON does not restrict the control plane architecture choice used,
either a co-located architecture or a physically separated either a co-located architecture or a physically separated
architecture may be used. A collection of links and nodes such as a architecture may be used. A collection of links and nodes such as a
sub-network or RA must be able to represent itself to the wider sub-network or RA must be able to represent itself to the wider
network as a single logical entity with only its external links network as a single logical entity with only its external links
visible to the topology database. visible to the topology database.
5. Evaluation 5. Evaluation
This section evaluates support of existing IETF routing protocols This section evaluates support of existing IETF routing protocols
with respect to the requirements summarized from [ASON-RR] in Section with respect to the requirements summarized from [ASON-RR] in Section
J.Drake et al. - Expires October 2005 3
4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The 4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The
latter in not addressed in the current version of this document. latter in not addressed in the current version of this document.
5.1 Terminology and Identification 5.1 Terminology and Identification
- Pi is a physical node (bearer/data/transport plane) node - Pi is a physical node (bearer/data/transport plane) node
- Li is a logical control plane identifier that is associated to a - Li is a logical control plane entity that is associated to a
single data plane (abstract) node i.e., the Logical Node ID single data plane (abstract) node. The Li is identified by the
TE Router_ID. The latter is a control plane identifier defined as
- TE Router_ID: control plane identifier that refers to the
. RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
. RFC 3784: Traffic Engineering Router ID TLV (Type 134) . RFC 3784: Traffic Engineering Router ID TLV (Type 134)
Note: both [RFC3630] and [RFC3784] make use of a single stable Note: this document does not define what the TE Router ID is. This
address to populate this identifier. document simply states the use of the TE Router ID to identify
the Li. Other documents (the referenced RFC 3630 and RFC
3784) provide the definitions.
- Ri is a logical control plane identifier that is associated to a - Ri is a logical control plane entity that is associated to a
control plane "router" e.g. (advertising) Router_ID i.e. control plane "router". The latter is the source for topology
information that it generates and shares with other control plane
"routers". The Ri is identified by the (advertising) Router_ID
. RFC 2328: Router ID (32-bit) . RFC 2328: Router ID (32-bit)
. RFC 1195: IS-IS System ID (48-bit) . RFC 1195: IS-IS System ID (48-bit)
The Router_ID, represented by Ri and that corresponds to the RC_ID The Router_ID, represented by Ri and that corresponds to the RC_ID
[ASON-REQ], does not enter into the identification of the logical [ASON-REQ], does not enter into the identification of the logical
entities representing the data plane resources such as links. The entities representing the data plane resources such as links. The
Routing DataBase (RDB) is associated to the Ri. Note that, in the Routing DataBase (RDB) is associated to the Ri. Note that, in the
ASON context, arrangement considering multiple Ri's announcing ASON context, arrangement considering multiple Ri's announcing
routing information related to a single Li is under evaluation. routing information related to a single Li is under evaluation.
Aside from the Li/Pi mappings, these identifiers are not assumed to Aside from the Li/Pi mappings, these identifiers are not assumed to
be in a particular entity relationship, e.g., an Ri may have be in a particular entity relationship except that the Ri may have
multiple Li in its scope. multiple Li in its scope. The relationship between Ri and Li is
simple at any moment in time: an Li may be advertised by only one Ri
at any time. However, an Ri may advertise a set of one or more Li's.
Thus, the routing protocol MUST be able to advertise multiple TE
Router IDs.
C.Hopps et al. - Expires January 2006 4
Note: Si is a control plane signaling function associated with one Note: Si is a control plane signaling function associated with one
or more Li. or more Li. This document does not assume any specific constraint on
the relationship between Si and Li. This document does not discuss
issues of control plane accessibility for signaling function, and
makes no assumptions about how control plane accessibility to the Si
is achieved.
5.2 RA Identification 5.2 RA Identification
G.7715.1 notes some necessary characteristics for RA identifiers, G.7715.1 notes some necessary characteristics for RA identifiers,
e.g., that they may provide scope for the Ri, and that they must be e.g., that they may provide scope for the Ri, and that they must be
provisioned to be unique within an administrative domain. The RA ID provisioned to be unique within an administrative domain. The RA ID
format itself is allowed to be derived from any global address space. format itself is allowed to be derived from any global address space.
Provisioning of RA IDs for uniqueness is outside the scope of this Provisioning of RA IDs for uniqueness is outside the scope of this
document. document.
Under these conditions, GMPLS link state routing protocols provide Under these conditions, GMPLS link state routing protocols provide
the capability for RA Identification. the capability for RA Identification.
5.3 Routing Information Exchange 5.3 Routing Information Exchange
We focus on routing information exchange between Ri entities We focus on routing information exchange between Ri entities
(through routing adjacencies) within single hierarchical level. (through routing adjacencies) within single hierarchical level.
J.Drake et al. - Expires October 2005 4
Routing information mapping between levels may require specific Routing information mapping between levels may require specific
guidelines. guidelines.
The control plane does not transport Pi information as these are The control plane does not transport Pi information as these are
data plane addresses for which the Li/Pi mapping is kept (link) data plane addresses for which the Li/Pi mapping is kept (link)
local - see for instance the transport LMP document [LMP-T] where local - see for instance the transport LMP document [LMP-T] where
such exchange is described. Example: the transport plane identifier such exchange is described. Example: the transport plane identifier
is the Pi (the identifier assigned to the physical element) which is the Pi (the identifier assigned to the physical element) that
could be for instance "666B.F999.AF10.222C", whereas the control could be for instance "666B.F999.AF10.222C", whereas the control
plane identifier is the Li (the identifier assigned by the control plane identifier is the Li (the identifier assigned by the control
plane), which could be for instance "1.1.1.1". plane), which could be for instance "1.1.1.1".
The control plane exchanges the control plane identifier information The control plane exchanges the control plane identifier information
but not the transport plane identifier information (i.e. not but not the transport plane identifier information (i.e. not
"666B.F999.AF10.222C" but only "1.1.1.1"). The mapping Li/Pi is kept "666B.F999.AF10.222C" but only "1.1.1.1"). The mapping Li/Pi is kept
local. So, when the Si receives a control plane message requesting local. So, when the Si receives a control plane message requesting
the use of "1.1.1.1", Si knows locally that this information refers the use of "1.1.1.1", Si knows locally that this information refers
to the data plane entity identified by the transport plane to the data plane entity identified by the transport plane
identifier "666B.F999.AF10.222C". identifier "666B.F999.AF10.222C".
The control plane carries: The control plane carries:
1) its view of the data plane link end-points and other link 1) its view of the data plane link end-points and other link
connection end-points connection end-points
2) the identifiers scoped by the Li's i.e. referred to as an 2) the identifiers scoped by the Li's i.e. referred to as an
associated IPv4/IPv6 addressing space associated IPv4/IPv6 addressing space
3) when using OSPF or ISIS as the IGP in support of traffic 3) when using OSPF or ISIS as the IGP in support of traffic
engineering, RFC 3477 RECOMMENDS that the Li value (referred to the engineering, RFC 3477 RECOMMENDS that the Li value (referred to the
"LSR Router ID") to be set to the TE Router ID value. Note that in "LSR Router ID") to be set to the TE Router ID value.
the ASON context, there may be cases where this is not desirable.
These cases are under evaluation. C.Hopps et al. - Expires January 2006 5
5.3.1 Link Attributes 5.3.1 Link Attributes
From the list of link attributes and characteristics (detailed in From the list of link attributes and characteristics (detailed in
[ASON-RR], the Local Adaptation support information is missing as TE [ASON-RR], the Local Adaptation support information is missing as TE
link attribute. GMPLS routing does not currently consider the use of link attribute. GMPLS routing does not currently consider the use of
dedicated TE link attribute(s) to describe the cross/inter-layer dedicated TE link attribute(s) to describe the cross/inter-layer
relationships. All other TE link attributes and characteristics are relationships. All other TE link attributes and characteristics are
currently covered (see Table 1.) currently covered (see Table 1.)
skipping to change at line 264 skipping to change at line 285
Descriptor (ISCD) that delivers information about the (maximum/ Descriptor (ISCD) that delivers information about the (maximum/
minimum) bandwidth per priority an LSP can make use of. In the ASON minimum) bandwidth per priority an LSP can make use of. In the ASON
context, other representations are possible, e.g., in terms of a set context, other representations are possible, e.g., in terms of a set
of tuples <signal_type; number of unallocated timeslots>. The latter of tuples <signal_type; number of unallocated timeslots>. The latter
also may require definition of additional signal types (from those also may require definition of additional signal types (from those
defined in [RFC 3496]) to represent contiguous concatenation i.e. defined in [RFC 3496]) to represent contiguous concatenation i.e.
STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
The method proposed in [GMPLS-RTG] is the most straightforward The method proposed in [GMPLS-RTG] is the most straightforward
without requiring any bandwidth accounting change from an LSR without requiring any bandwidth accounting change from an LSR
J.Drake et al. - Expires October 2005 5
perspective. However, it introduces some lost of information. This perspective. However, it introduces some lost of information. This
lost of information affects the number of signals that can be used lost of information affects the number of signals that can be used
but not the range they cover. On the other hand, if additional but not the range they cover. On the other hand, if additional
technology specific information (such as capabilities) are technology specific information (such as capabilities) are
advertised a finer grained resource countdown and accounting can be advertised a finer grained resource countdown and accounting can be
performed allowing for network wide resource allocation in Sonet/SDH performed allowing for network wide resource allocation in Sonet/SDH
environments. environments.
Link Characteristics GMPLS OSPF Link Characteristics GMPLS OSPF
----------------------- ---------- ----------------------- ----------
skipping to change at line 296 skipping to change at line 315
Interface Switching Capability Descriptor Interface Switching Capability Descriptor
sub-TLV [GMPLS-OSPF] sub-TLV [GMPLS-OSPF]
Link Capacity Unreserved bandwidth sub-TLV [RFC3630] Link Capacity Unreserved bandwidth sub-TLV [RFC3630]
Max LSP Bandwidth part of the Interface Max LSP Bandwidth part of the Interface
Switching Capability Descriptor sub-TLV Switching Capability Descriptor sub-TLV
[GMPLS-OSPF] [GMPLS-OSPF]
Link Availability Link Protection sub-TLV [GMPLS-OSPF] Link Availability Link Protection sub-TLV [GMPLS-OSPF]
Diversity Support SRLG sub-TLV [GMPLS-OSPF] Diversity Support SRLG sub-TLV [GMPLS-OSPF]
Local Adaptation support see above Local Adaptation support see above
C.Hopps et al. - Expires January 2006 6
Link Characteristics GMPLS IS-IS Link Characteristics GMPLS IS-IS
----------------------- ----------- ----------------------- -----------
Local SNPP link ID Link local part of the TE link identifier Local SNPP link ID Link local part of the TE link identifier
sub-TLV [GMPLS-ISIS] sub-TLV [GMPLS-ISIS]
Remote SNPP link ID Link remote part of the TE link identifier Remote SNPP link ID Link remote part of the TE link identifier
sub-TLV [GMPLS-ISIS] sub-TLV [GMPLS-ISIS]
Signal Type Technology specific part of the Interface Signal Type Technology specific part of the Interface
Switching Capability Descriptor sub-TLV Switching Capability Descriptor sub-TLV
[GMPLS-ISIS] [GMPLS-ISIS]
Link Weight TE Default metric [RFC3784] Link Weight TE Default metric [RFC3784]
skipping to change at line 318 skipping to change at line 338
Interface Switching Capability Descriptor Interface Switching Capability Descriptor
sub-TLV [GMPLS-ISIS] sub-TLV [GMPLS-ISIS]
Link Capacity Unreserved bandwidth sub-TLV [RFC3784] Link Capacity Unreserved bandwidth sub-TLV [RFC3784]
Max LSP Bandwidth part of the Interface Max LSP Bandwidth part of the Interface
Switching Capability Descriptor sub-TLV Switching Capability Descriptor sub-TLV
[GMPLS-ISIS] [GMPLS-ISIS]
Link Availability Link Protection sub-TLV [GMPLS-ISIS] Link Availability Link Protection sub-TLV [GMPLS-ISIS]
Diversity Support SRLG sub-TLV [GMPLS-ISIS] Diversity Support SRLG sub-TLV [GMPLS-ISIS]
Local Adaptation support see above Local Adaptation support see above
J.Drake et al. - Expires October 2005 6
Table 1. TE link Attribute in GMPLS OSPF-TE and GMPLS IS-IS-TE, Table 1. TE link Attribute in GMPLS OSPF-TE and GMPLS IS-IS-TE,
respectively respectively
Note: Link Attributes represent layer resource capabilities and
their utilization.
5.3.2 Node Attributes 5.3.2 Node Attributes
Nodes attributes include the "Logical Node ID" (as detailed in Nodes attributes include the "Logical Node ID" (as detailed in
Section 5.1) and the reachability information as described in Section 5.1) and the reachability information as described in
Section 5.3.3. Section 5.3.3.
5.3.3 Reachability Information 5.3.3 Reachability Information
Advertisement of reachability can be achieved using the techniques Advertisement of reachability can be achieved using the techniques
described in [OSPF-NODE] where the set of local addresses are described in [OSPF-NODE] where the set of local addresses are
carried in a OSPF TE LSA node attribute TLV (a specific sub-TLV is carried in an OSPF TE LSA node attribute TLV (a specific sub-TLV is
defined per address family, e.g., IPv4 and IPv6). However, [OSPF- defined per address family, e.g., IPv4 and IPv6). However, [OSPF-
NODE] restricts to advertisement of Host addresses and not prefixes, NODE] restricts to advertisement of Host addresses and not prefixes,
and therefore requires enhancement (see below). and therefore requires enhancement (see below).
A similar mechanism does not exist for IS-IS as the Extended IP A similar mechanism does not exist for IS-IS as the Extended IP
Reachability TLV [RFC3784] focuses on IP reachable end-points Reachability TLV [RFC3784] focuses on IP reachable end-points
(terminating points), as its name indicates. (terminating points), as its name indicates.
In order to advertise blocks of reachable address prefixes a In order to advertise blocks of reachable address prefixes a
summarization mechanism is additionally required. This mechanism may summarization mechanism is additionally required. This mechanism may
take the form of an prefix length (that indicates the number of take the form of an prefix length (that indicates the number of
significant bits in the prefix) or a network mask. significant bits in the prefix) or a network mask.
C.Hopps et al. - Expires January 2006 7
5.4 Routing Information Abstraction 5.4 Routing Information Abstraction
G.7715.1 describes both static and dynamic methods for abstraction of G.7715.1 describes both static and dynamic methods for abstraction of
routing information for advertisement at a different level of the routing information for advertisement at a different level of the
routing hierarchy. However, the information that is advertised routing hierarchy. However, the information that is advertised
continues to be in the form of link and node advertisements continues to be in the form of link and node advertisements
consistent with the link state routing protocol used at that level, consistent with the link state routing protocol used at that level,
hence no specific capabilities are added to the routing protocol hence no specific capabilities are added to the routing protocol
beyond the ability to locally identify when routing information beyond the ability to locally identify when routing information
originates outside of a particular RA. originates outside of a particular RA.
skipping to change at line 371 skipping to change at line 395
hierarchical levels of RAs hierarchical levels of RAs
G.7715.1 does not define specific mechanisms to support multiple G.7715.1 does not define specific mechanisms to support multiple
hierarchical levels of RAs, beyond the ability to support abstraction hierarchical levels of RAs, beyond the ability to support abstraction
as discussed above. However, if RCs bound to adjacent levels of the as discussed above. However, if RCs bound to adjacent levels of the
RA hierarchy were allowed to redistribute routing information in RA hierarchy were allowed to redistribute routing information in
both directions between adjacent levels of the hierarchy without any both directions between adjacent levels of the hierarchy without any
additional mechanisms, they would not be able to determine looping additional mechanisms, they would not be able to determine looping
of routing information. of routing information.
J.Drake et al. - Expires October 2005 7
To prevent this looping of routing information between levels, IS-IS To prevent this looping of routing information between levels, IS-IS
[RFC1195] allows only advertising routing information upward in the [RFC1195] allows only advertising routing information upward in the
level hierarchy, and disallow the advertising of routing information level hierarchy, and disallow the advertising of routing information
downward in the hierarchy. [RFC2966] defines the up/down bit to downward in the hierarchy. [RFC2966] defines the up/down bit to
allow advertising downward in the hierarchy the "IP Internal allow advertising downward in the hierarchy the "IP Internal
Reachability Information" TLV (Type 128) and "IP External Reachability Information" TLV (Type 128) and "IP External
Reachability Information" TLV (Type 130). [RFC3784] extends its Reachability Information" TLV (Type 130). [RFC3784] extends its
applicability for the "Extended IP Reachability" TLV (Type 135). applicability for the "Extended IP Reachability" TLV (Type 135).
Using this mechanism, the up/down bit is set to 0 when routing Using this mechanism, the up/down bit is set to 0 when routing
information is first injected into IS-IS. If routing information is information is first injected into IS-IS. If routing information is
advertised from a higher level to a lower level, the up/down bit is advertised from a higher level to a lower level, the up/down bit is
set to 1, indicating that it has traveled down the hierarchy. set to 1, indicating that it has traveled down the hierarchy.
Routing information that have the up/down bit set to 1 may only be Routing information that has the up/down bit set to 1 may only be
advertised down the hierarchy, i.e. to lower levels. This mechanisms advertised down the hierarchy, i.e. to lower levels. This mechanism
applies independently of the number of levels. However, this applies independently of the number of levels. However, this
mechanism does not apply to the "Extended IS Reachability" TLV (Type mechanism does not apply to the "Extended IS Reachability" TLV (Type
22) used to propagate the summarized topology (see Section 5.3), 22) used to propagate the summarized topology (see Section 5.3),
traffic engineering information as listed in Table 1, as well as traffic engineering information as listed in Table 1, as well as
reachability information (see Section 5.3.3). reachability information (see Section 5.3.3).
OSPFv2 prevents that inter-area routes which are learned from area 0 OSPFv2 prevents that inter-area routes, which are learned from area
are not passed back to area 0. However, GMPLS makes use of Type 10 0 are not passed back to area 0. However, GMPLS makes use of Type 10
(area-local scope) LSA to propagate TE information [RFC3630], [GMPLS- (area-local scope) LSA to propagate TE information [RFC3630], [GMPLS-
RTG]. Type 10 Opaque LSAs are not flooded beyond the borders of RTG]. Type 10 Opaque LSAs are not flooded beyond the borders of
their associated area. It is therefore necessary to have a means by their associated area. It is therefore necessary to have a means by
which Type 10 Opaque LSA may carry the information that a particular which Type 10 Opaque LSA may carry the information that particular
routing information has been learned from a higher level RC when routing information has been learned from a higher level RC when
propagated to a lower level RC. Any downward RC from this level
C.Hopps et al. - Expires January 2006 8
propagated to a lower level RC. Any downward RC from this level,
which receives an LSA with this information would omit the which receives an LSA with this information would omit the
information in this LSA and thus not re-introduce this information information in this LSA and thus not re-introduce this information
back into an higher level RC. back into an higher level RC.
5.6 Routing Protocol Convergence 5.6 Routing Protocol Convergence
Link state protocols have been designed to detect topological Link state protocols have been designed to detect topological
changes (such as interface failures, link attributes modification). changes (such as interface failures, link attributes modification).
Convergence period is short and involves a minimum of routing Convergence period is short and involves a minimum of routing
information exchange. information exchange.
Therefore, existing routing protocol convergence mechanisms are Therefore, existing routing protocol convergence mechanisms are
sufficient for ASON applications. sufficient for ASON applications.
5.7 Routing Information Scoping
The routing protocol MUST support a single Ri advertising on behalf
of more than one Li. Since each Li is identified by a unique
TE Router ID, the routing protocol MUST be able to advertise
multiple TE Router IDs.
The Link sub-TLV currently part of the top level Link TLV associates
the link to the Router_ID. However, having the Ri advertising on
behalf multiple Li's creates the following issue as there is no more
a 1:1 relationship between the Router_ID and the TE Router_ID but a
1:N relationship is possible (see Section 5.1). As the link local
and link remote (unnumbered) ID association may be not unique per
abstract node (per Li unicity), the TE link advertisement needs to
additionally indicate the remote Lj value such as to unambiguously
retrieve the [Li;Lj] relationship(s). In 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 local Li. Therefore,
the routing protocol MUST be able to disambiguate the advertised TE
links so that they can be associated with the correct TE Router ID.
Moreover, when the Ri advertises on behalf multiple Li's, the
routing protocol MUST be able to disambiguate the advertised
reachability information (see Section 5.3.3) so that it can be
associated with the correct TE Router ID.
6. Evaluation Scenarios 6. Evaluation Scenarios
The evaluation scenarios are the following: referred to as The evaluation scenarios are the following: referred to as
respectively case 1), 2), 3) and 4). Additional base scenarios respectively case 1), 2), 3) and 4). Additional base scenarios
(being not combinations or decomposition of entities) may further (being not combinations or decomposition of entities) may further
complete this set in a future revision of this document. complete this set in a future revision of this document.
In the below Figure 1: In the below Figure 1:
- R3 represents an LSR with all components collocated. - R3 represents an LSR with all components collocated.
- R2 shows how the "router" component may be disjoint from the node - R2 shows how the "router" component may be disjoint from the node
J.Drake et al. - Expires October 2005 8 C.Hopps et al. - Expires January 2006 9
- R1 shows how a single "router" may manage multiple nodes - R1 shows how a single "router" may manage multiple nodes
------------------- ------- ------------------- -------
|R1 | |R2 | |R1 | |R2 |
| | | | ------ | | | | ------
| L1 L2 L3 | | L4 | |R3 | | L1 L2 L3 | | L4 | |R3 |
| : : : | | : | | | | : : : | | : | | |
| : : : | | : | | L5 | | : : : | | : | | L5 |
Control ---+-----+-----+--- ---+--- | : | Control ---+-----+-----+--- ---+--- | : |
Plane : : : : | : | Plane : : : : | : |
skipping to change at line 479 skipping to change at line 530
Node as represented in the below figure. There is no internal Node as represented in the below figure. There is no internal
structure associated (externally) to the abstract node. structure associated (externally) to the abstract node.
-------------- --------------
|R4 | |R4 |
| | | |
| L6 | | L6 |
| : | | : |
| ...... | | ...... |
J.Drake et al. - Expires October 2005 9 C.Hopps et al. - Expires January 2006 10
---:------:--- ---:------:---
Control Plane : : Control Plane : :
+------+------+------+ +------+------+------+
Data Plane : : Data Plane : :
---:------:--- ---:------:---
|P8 : : | |P8 : : |
| -- -- | | -- -- |
--+-|P |----|P |-+-- --+-|P |----|P |-+--
| -- -- | | -- -- |
-------------- --------------
skipping to change at line 514 skipping to change at line 565
8.1 Normative References 8.1 Normative References
[GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in [GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in
Support of Generalized MPLS," Internet Draft (work in Support of Generalized MPLS," Internet Draft (work in
progress), draft-ietf-ccamp-gmpls-routing-09.txt, progress), draft-ietf-ccamp-gmpls-routing-09.txt,
October 2003. October 2003.
[LMP-T] D.Fedyk et al., "A Transport Network View of LMP," [LMP-T] D.Fedyk et al., "A Transport Network View of LMP,"
Internet Draft (work in progress), draft-ietf-ccamp- Internet Draft (work in progress), draft-ietf-ccamp-
transport-lmp-01, February 2005. transport-lmp-02, May 2005.
[OSPF-NODE] R.Aggarwal, and K.Kompella, "Advertising a Router's [OSPF-NODE] R.Aggarwal, and K.Kompella, "Advertising a Router's
Local Addresses in OSPF TE Extensions," Internet Draft, Local Addresses in OSPF TE Extensions," Internet Draft,
(work in progress), draft-ietf-ospf-te-node-addr- (work in progress), draft-ietf-ospf-te-node-addr-
01.txt, July 2004. 02.txt, March 2005.
[RFC2026] S.Bradner, "The Internet Standards Process -- [RFC2026] S.Bradner, "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996. Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2328] J.Moy, "OSPF Version 2", RFC 2328, April 1998. [RFC2328] J.Moy, "OSPF Version 2", RFC 2328, April 1998.
[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.
[RFC3477] K.Kompella et al. "Signalling Unnumbered Links in [RFC3477] K.Kompella et al. "Signalling Unnumbered Links in
Resource ReSerVation Protocol - Traffic Engineering Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, January 2003.
J.Drake et al. - Expires October 2005 10 C.Hopps et al. - Expires January 2006 11
[RFC3630] D.Katz et al. "Traffic Engineering (TE) Extensions to [RFC3630] D.Katz et al. "Traffic Engineering (TE) Extensions to
OSPF Version 2", RFC 3630, September 2003. OSPF Version 2", RFC 3630, September 2003.
[RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004. RFC 3667, February 2004.
[RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
[RFC3784] H.Smit and T.Li, "Intermediate System to Intermediate [RFC3784] H.Smit and T.Li, "Intermediate System to Intermediate
skipping to change at line 556 skipping to change at line 607
[RFC3946] E.Mannie, and D.Papadimitriou, (Editors) et al., [RFC3946] E.Mannie, and D.Papadimitriou, (Editors) et al.,
"Generalized Multi-Protocol Label Switching Extensions "Generalized Multi-Protocol Label Switching Extensions
for SONET and SDH Control," RFC 3946, October 2004. for SONET and SDH Control," RFC 3946, October 2004.
8.2 Informative References 8.2 Informative References
[ASON-RR] W.Alanqar et al. "Requirements for Generalized MPLS [ASON-RR] W.Alanqar et al. "Requirements for Generalized MPLS
(GMPLS) Routing for Automatically Switched Optical (GMPLS) Routing for Automatically Switched Optical
Network (ASON)," Work in progress, draft-ietf-ccamp- Network (ASON)," Work in progress, draft-ietf-ccamp-
gmpls-ason-routing-reqts-04.txt, May 2004. gmpls-ason-routing-reqts-05.txt, October 2004.
For information on the availability of ITU Documents, please see For information on the availability of ITU Documents, please see
http://www.itu.int http://www.itu.int
[G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and
Requirements for the Automatically Switched Optical Requirements for the Automatically Switched Optical
Network (ASON)," June 2002. Network (ASON)," June 2002.
[G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing
Architecture and Requirements for Link State Protocols," Architecture and Requirements for Link State Protocols,"
November 2003. November 2003.
[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)," Automatically Switched Optical Network (ASON),"
November 2001 (and Revision, January 2003). November 2001 (and Revision, January 2003).
9. Author's Addresses (to be completed) 9. Author's Addresses
Lyndon Ong (Ciena Corporation) Lyndon Ong (Ciena Corporation)
PO Box 308 PO Box 308
Cupertino, CA 95015 , USA Cupertino, CA 95015 , USA
Phone: +1 408 705 2978 Phone: +1 408 705 2978
EMail: lyong@ciena.com EMail: lyong@ciena.com
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Francis Wellensplein 1, Francis Wellensplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 2408491 Phone: +32 3 2408491
J.Drake et al. - Expires October 2005 11 C.Hopps et al. - Expires January 2006 12
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
Jonathan Sadler Jonathan Sadler
1415 W. Diehl Rd 1415 W. Diehl Rd
Naperville, IL 60563 Naperville, IL 60563
EMail: jonathan.sadler@tellabs.com EMail: jonathan.sadler@tellabs.com
Stephen Shew (Nortel Networks) Stephen Shew (Nortel Networks)
PO Box 3511 Station C PO Box 3511 Station C
Ottawa, Ontario, CANADA K1Y 4H7 Ottawa, Ontario, CANADA K1Y 4H7
Phone: +1 613 7632462 Phone: +1 613 7632462
EMail: sdshew@nortelnetworks.com EMail: sdshew@nortelnetworks.com
J.Drake et al. - Expires October 2005 12 Dave Ward (Cisco Systems)
170 W. Tasman Dr.
San Jose, CA 95134 USA
Phone: +1-408-526-4000
EMail: dward@cisco.com
C.Hopps et al. - Expires January 2006 13
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
which belong to a single player such as a network operator, a service which belong to a single player such as a network operator, a service
provider, or an end-user. Administrative domains of different players provider, or an end-user. Administrative domains of different players
do not overlap amongst themselves. do not overlap amongst themselves.
skipping to change at line 655 skipping to change at line 712
control in a consistent manner. Management domains can be disjoint, control in a consistent manner. Management domains can be disjoint,
contained or overlapping. As such the resources within an contained or overlapping. As such the resources within an
administrative domain can be distributed into several possible administrative domain can be distributed into several possible
overlapping management domains. The same resource can therefore overlapping management domains. The same resource can therefore
belong to several management domains simultaneously, but a management belong to several management domains simultaneously, but a management
domain shall not cross the border of an administrative domain. domain shall not cross the border of an administrative domain.
Subnetwork Point (SNP): The SNP is a control plane abstraction that Subnetwork Point (SNP): The SNP is a control plane abstraction that
represents an actual or potential transport plane resource. SNPs (in represents an actual or potential transport plane resource. SNPs (in
J.Drake et al. - Expires October 2005 13 C.Hopps et al. - Expires January 2006 14
different subnetwork partitions) may represent the same transport different subnetwork partitions) may represent the same transport
resource. A one-to-one correspondence should not be assumed. resource. A one-to-one correspondence should not be assumed.
Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together
for the purposes of routing. for the purposes of routing.
Termination Connection Point (TCP): A TCP represents the output of a Termination Connection Point (TCP): A TCP represents the output of a
Trail Termination function or the input to a Trail Termination Sink Trail Termination function or the input to a Trail Termination Sink
function. function.
Transport plane: provides bi-directional or unidirectional transfer Transport plane: provides bi-directional or unidirectional transfer
of user information, from one location to another. It can also of user information, from one location to another. It can also
provide transfer of some control and network management information. provide transfer of some control and network management information.
The Transport Plane is layered; it is equivalent to the Transport The Transport Plane is layered; it is equivalent to the Transport
Network defined in G.805 Recommendation. Network defined in G.805 Recommendation.
User Network Interface (UNI): interfaces are located between protocol User Network Interface (UNI): interfaces are located between protocol
controllers between a user and a control domain. Note: there is no controllers between a user and a control domain. Note: there is no
routing function associated with a UNI reference point. routing function associated with a UNI reference point.
J.Drake et al. - Expires October 2005 14 C.Hopps et al. - Expires January 2006 15
Appendix 2: ASON Routing Terminology Appendix 2: ASON Routing Terminology
This document makes use of the following terms: This document makes use of the following terms:
Routing Area (RA): a RA represents a partition of the data plane and Routing Area (RA): a RA represents a partition of the data plane and
its identifier is used within the control plane as the representation its identifier is used within the control plane as the representation
of this partition. Per [G.8080] a RA is defined by a set of sub- of this partition. Per [G.8080] a RA is defined by a set of sub-
networks, the links that interconnect them, and the interfaces networks, the links that interconnect them, and the interfaces
representing the ends of the links exiting that RA. A RA may contain representing the ends of the links exiting that RA. A RA may contain
skipping to change at line 720 skipping to change at line 777
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 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.
J.Drake et al. - Expires October 2005 15 C.Hopps et al. - Expires January 2006 16
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights. it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC Information on the procedures with respect to rights in RFC
skipping to change at line 767 skipping to change at line 824
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
J.Drake et al. - Expires October 2005 16 C.Hopps et al. - Expires January 2006 17
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/