draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt   rfc4652.txt 
CCAMP Working Group Chris Hopps (Cisco) Network Working Group D. Papadimitriou, Ed.
Internet Draft Lyndon Ong (Ciena) Request for Comments: 4652 Alcatel
Category: Informational Dimitri Papadimitriou (Alcatel) Category: Informational L.Ong
Jonathan Sadler (Tellabs) Ciena
Expiration Date: December 2006 Stephen Shew (Nortel) J. Sadler
Dave Ward (Cisco) Tellabs
Evaluation of existing Routing Protocols S. Shew
against ASON routing requirements Nortel
D. Ward
draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt Cisco
October 2006
Status of this Memo
By submitting this Internet-Draft, each author represents that any Evaluation of Existing Routing Protocols against
applicable patent or other IPR claims of which he or she is aware Automatic Switched Optical Network (ASON) Routing Requirements
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This memo provides information for the Internet community. It does
months and may be updated, replaced, or obsoleted by other documents not specify an Internet standard of any kind. Distribution of this
at any time. It is inappropriate to use Internet-Drafts as reference memo is unlimited.
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2006).
http://www.ietf.org/shadow.html.
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 Synchronous Optical Network/Synchronous Digital Hierarchy
(SONET/SDH) and Optical Transport Networks (OTNs).
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.
C.Hopps et al. - Expires December 2006 1 1. Introduction
1. Contributors
This document is the result of the CCAMP Working Group ASON Routing
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
The reader is expected to be familiar with the terminology introduced
in [RFC4258].
3. Introduction
There are certain capabilities that are needed to support the ITU-T Certain capabilities are needed to support the ITU-T Automatically
Automatically Switched Optical Network (ASON) control plane Switched Optical Network (ASON) control plane architecture as defined
architecture as defined in [G.8080]. in [G.8080].
[RFC4258] details the routing requirements for the GMPLS routing [RFC4258] details the routing requirements for the GMPLS routing
suite of protocols to support the capabilities and functionality of suite of protocols to support the capabilities and functionality of
ASON control planes identified in [G.7715] and in [G.7715.1]. The ASON control planes identified in [G.7715] and in [G.7715.1]. The
ASON routing architecture provides for a conceptual reference ASON routing architecture provides for a conceptual reference
architecture, with definition of functional components and common architecture, with definition of functional components and common
information elements to enable end-to-end routing in the case of information elements to enable end-to-end routing in the case of
protocol heterogeneity and facilitate management of ASON networks. protocol heterogeneity and to facilitate management of ASON networks.
This description is only conceptual: no physical partitioning of This description is only conceptual: no physical partitioning of
these functions is implied. these functions is implied.
However, [RFC4258] does not address GMPLS routing protocol However, [RFC4258] 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 [RFC4258]. Routing Protocols against the requirements identified in [RFC4258].
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 Appendices A and
B.
C.Hopps et al. - Expires January 2006 2 2. Conventions Used in This Document
4. Requirements - Overview The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
The reader is expected to be familiar with the terminology introduced
in [RFC4258].
3. Contributors
This document is the result of the CCAMP Working Group ASON Routing
Solution design team's 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@nortel.com
Dave Ward (Cisco)
EMail: dward@cisco.com
4. Requirements: Overview
The following functionality is expected from GMPLS routing protocols The following functionality is expected from GMPLS routing protocols
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
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
routing protocol used. protocol used.
- The routing protocol shall converge such that the distributed - The routing protocol shall converge such that the distributed
Routing DataBases (RDB) become synchronized after a period of Routing DataBases (RDB) become synchronized after a period of time.
time.
To support dissemination of hierarchical routing information, the To support dissemination of hierarchical routing information, the
routing protocol must deliver: routing protocol must deliver:
- Processing of routing information exchanged between adjacent
levels of the hierarchy (i.e. Level N+1 and N) including - Processing of routing information exchanged between adjacent levels
reachability, and (upon policy decision) summarized topology of the hierarchy (i.e., Level N+1 and N), including reachability
information. and (upon policy decision) summarized topology information.
- Self-consistent information at the receiving level resulting from - Self-consistent information at the receiving level resulting from
any transformation (filter, summarize, etc.) and forwarding of any transformation (filter, summarize, etc.) and forwarding of
information from one Routing Controller (RC) to RC(s) at different information from one Routing Controller (RC) to RC(s) at different
levels when multiple RCs are bound to a single RA. levels when multiple RCs are bound to a single RA.
- A mechanism to prevent re-introduction of information propagated - A mechanism to prevent re-introduction of information propagated
into the Level N RA's RC back to the adjacent level RA's RC from into the Level N RA's RC back to the adjacent level RA's RC from
which this information has been initially received. which this information has been initially received.
Note: the number of hierarchical levels to be supported is routing Note: The number of hierarchical levels to be supported is routing
protocol specific and reflects a containment relationship. protocol specific and reflects a containment relationship.
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 as 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
not restrict the choice of routing protocols for use in other RAs should not restrict the choice of routing protocols for use in other
(child or parent). RAs (child or parent).
C.Hopps et al. - Expires January 2006 3
As ASON does not restrict the control plane architecture choice, As ASON does not restrict the control plane architecture choice,
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 [RFC4258] in Section with respect to the requirements summarized from [RFC4258] in Section
4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The 4. Candidate routing protocols are Interior Gateway Protocol (IGP)
latter is not addressed in the current version of this document. BGP (OSPF and Intermediate System to Intermediate System (IS-IS)) and
is not considered a candidate protocol mainly because of BGP. The latter is not addressed in the current version of this
- non-support of TE information exchange: each BGP router advertises document. BGP is not considered a candidate protocol mainly because
of the following reasons:
- Non-support of TE information exchange. Each BGP router advertises
only its path to each destination in its vector for loop avoidance, only its path to each destination in its vector for loop avoidance,
with no costs or hop counts; each BGP router knows little about with no costs or hop counts; each BGP router knows little about
network topology network topology.
- BGP can only advertise routes that are eligible for use (local RIB) - BGP can only advertise routes that are eligible for use (local RIB)
or routing loops can occur; there is one best route per prefix, and or routing loops can occur; there is one best route per prefix, and
that is the route that is advertised. that is the route that is advertised.
- BGP is not widely deployed in optical equipment and networks
5.1 Terminology and Identification - BGP is not widely deployed in optical equipment and networks.
- Pi is a physical (bearer/data/transport plane) node 5.1. Terminology and Identification
- Li is a logical control plane entity that is associated to a - Pi is a physical (bearer/data/transport plane) node.
single data plane (abstract) node. The Li is identified by the
TE Router_ID. The latter is a control plane identifier defined as - Li is a logical control plane entity that is associated to a single
data plane (abstract) node. The Li is identified by the TE
Router_ID. The latter is a control plane identifier defined as
follows: follows:
. [RFC 3630]: Router_Address (top level) TLV of the Type 1 TE LSA
. [RFC 3784]: Traffic Engineering Router ID TLV (Type 134)
Note: this document does not define what the TE Router ID is. This [RFC3630]: Router_Address (top level) TLV of the Type 1 TE LSA
document simply states the use of the TE Router ID to [RFC3784]: Traffic Engineering Router ID TLV (Type 134)
identify Li. [RFC 3630] and [RFC3784] provide the definitions.
Note: This document does not define what the TE Router ID is. This
document simply states the use of the TE Router ID to identify Li.
[RFC3630] and [RFC3784] provide the definitions.
- Ri is a logical control plane entity that is associated to a - Ri is a logical control plane entity that is associated to a
control plane "router". The latter is the source for topology control plane "router". The latter is the source for topology
information that it generates and shares with other control plane information that it generates and shares with other control plane
"routers". The Ri is identified by the (advertising) Router_ID "routers". The Ri is identified by the (advertising) Router_ID
. [RFC 2328]: Router ID (32-bit)
. [RFC 1195]: IS-IS System ID (48-bit)
The Router_ID, represented by Ri and that corresponds to the RC_ID [RFC2328]: Router ID (32-bit)
[RFC4258], does not enter into the identification of the logical [RFC1195]: IS-IS System ID (48-bit)
entities representing the data plane resources such as links. The
Routing DataBase (RDB) is associated to the Ri. Note that, in the The Router_ID, which is represented by Ri and which corresponds to
ASON context, an arrangement consisting of multiple Ri's the RC_ID [RFC4258], does not enter into the identification of the
announcing routing information related to a single Li is under logical entities representing the data plane resources such as
links. The Routing DataBase (RDB) is associated to the Ri. Note
that, in the ASON context, an arrangement consisting of multiple
Ris announcing routing information related to a single Li is under
evaluation. evaluation.
C.Hopps et al. - Expires January 2006 4
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 except that the Ri may have be in a particular entity relationship except that the Ri may have
multiple Li in its scope. The relationship between Ri and Li is multiple Lis 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 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. at any time. However, an Ri may advertise a set of one or more Lis.
Thus, the routing protocol MUST be able to advertise multiple TE Thus, the routing protocol MUST be able to advertise multiple TE
Router IDs (see Section 5.7). Router IDs (see Section 5.7).
Note: Si is a control plane signaling function associated with one Note: Si is a control plane signaling function associated with one or
or more Li. This document does not assume any specific constraint on more Lis. This document does not assume any specific constraint on
the relationship between Si and Li. This document does not discuss the relationship between Si and Li. This document does not discuss
issues of control plane accessibility for the signaling function, issues of control plane accessibility for the signaling function, and
and makes no assumptions about how control plane accessibility to it makes no assumptions about how control plane accessibility to the
the Si is achieved. 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 without further modification. the capability for RA Identification without further modification.
5.3 Routing Information Exchange 5.3. Routing Information Exchange
In this section, the focus is on routing information exchange Ri In this section, the focus is on routing information exchange Ri
entities (through routing adjacencies) within a single hierarchical entities (through routing adjacencies) within a single hierarchical
level. Routing information mapping between levels require specific level. Routing information mapping between levels require specific
processing (see Section 5.5). processing (see Section 5.5).
The control plane does not transport Pi identifiers as these are The control plane does not transport Pi identifiers, 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 [RFC4394] where local; see, for instance the transport LMP document [RFC4394] where
such an exchange is described. Example: the transport plane such an exchange is described. Example: The transport plane
identifier is the Pi (the identifier assigned to the physical identifier is the Pi (the identifier assigned to the physical
element) that could be for instance "666B.F999.AF10.222C", whereas element) that 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 "192.0.2.1". the control plane), which could be, for instance, "192.0.2.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 "192.0.2.1"). The mapping Li/Pi is "666B.F999.AF10.222C", but only "192.0.2.1"). The mapping Li/Pi is
kept local. So, when the Si receives a control plane message kept local. So, when the Si receives a control plane message
requesting the use of "192.0.2.1", Si knows locally that this requesting the use of "192.0.2.1", Si knows locally that this
information refers to the data plane entity identified by the information refers to the data plane entity identified by the
transport plane identifier "666B.F999.AF10.222C". transport plane identifier "666B.F999.AF10.222C".
C.Hopps et al. - Expires January 2006 5
Note also that the Li and Pi addressing spaces may be identical. Note also that the Li and Pi addressing spaces may be identical.
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
associated IPv4/IPv6 addressing space; note that these identifiers 2) the identifiers scoped by the Lis, i.e., referred to as an
may either be bundled TE link addresses or component link addresses associated IPv4/IPv6 addressing space. Note that these
identifiers may be either bundled TE link addresses or component
link addresses.
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 engineering, [RFC 3477] RECOMMENDS that the Li value (referred to
the "LSR Router ID") to be set to the TE Router ID value. the "LSR Router ID") be set to the TE Router ID value.
Therefore, OSPF and IS-IS carry sufficient node identification Therefore, OSPF and IS-IS carry sufficient node identification
information without further modification. information without further modification.
5.3.1 Link Attributes 5.3.1. Link Attributes
[RFC4258] provides a list of link attributes and characteristics [RFC4258] provides a list of link attributes and characteristics that
that need to be advertised by a routing protocol. All TE link need to be advertised by a routing protocol. All TE link attributes
attributes and characteristics are currently handled by OSPF and IS- and characteristics are currently handled by OSPF and IS-IS (see
IS (see Table 1) with the exception of Local Adaptation support. Table 1) with the exception of Local Adaptation support. Indeed,
Indeed, GMPLS routing does not currently consider the use of GMPLS routing does not currently consider the use of dedicated TE
dedicated TE link attribute(s) to describe the cross/inter-layer link attribute(s) to describe the cross/inter-layer relationships.
relationships.
In addition, the representation of bandwidth requires further In addition, the representation of bandwidth requires further
consideration. GMPLS Routing defines an Interface Switching consideration. GMPLS Routing defines an Interface Switching
Capability Descriptor (ISCD) that delivers information about the Capability Descriptor (ISCD) that delivers information about the
(maximum/ minimum) bandwidth per priority of which an LSP can make (maximum/ minimum) bandwidth per priority of which an LSP can make
use. This information is usually used in combination with the use. This information is usually used in combination with the
Unreserved Bandwidth sub-TLV that provides the amount of bandwidth Unreserved Bandwidth sub-TLV that provides the amount of bandwidth
not yet reserved on a TE link. not yet reserved on a TE link.
In the ASON context, other bandwidth accounting representations are In the ASON context, other bandwidth accounting representations are
possible, e.g., in terms of a set of tuples <signal_type; number of possible, e.g., in terms of a set of tuples <signal_type; number of
unallocated timeslots>. The latter representation may also require unallocated timeslots>. The latter representation may also require
definition of additional signal types (from those defined in definition of additional signal types (from those defined in
[RFC3946]) to represent support of contiguously concatenated signals [RFC3946]) to represent support of contiguously concatenated signals,
i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256. i.e., STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
However, the method proposed in [RFC4202] is the most However, the method proposed in [RFC4202] is the most straightforward
straightforward without requiring any bandwidth accounting change without requiring any bandwidth accounting change from an LSR
from an LSR perspective (in particular, when the ISCD sub-TLV perspective (in particular, when the ISCD sub-TLV information is
information is combined with the information provided by the combined with the information provided by the Unreserved Bandwidth
Unreserved Bandwidth sub-TLV). sub-TLV).
Link Characteristics GMPLS OSPF Link Characteristics GMPLS OSPF
----------------------- ---------- ----------------------- ----------
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 [RFC4203] sub-TLV [RFC4203]
C.Hopps et al. - Expires January 2006 6
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 [RFC4203] sub-TLV [RFC4203]
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
[RFC4203] [RFC4203]
Link Weight TE metric sub-TLV [RFC3630] Link Weight TE metric sub-TLV [RFC3630]
Resource Class Administrative Group sub-TLV [RFC3630] Resource Class Administrative Group sub-TLV [RFC3630]
Local Connection Types Switching Capability field part of the Local Connection Types Switching Capability field part of the
Interface Switching Capability Descriptor Interface Switching Capability Descriptor
sub-TLV [RFC4203] sub-TLV [RFC4203]
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
[RFC4203] [RFC4203]
Link Availability Link Protection sub-TLV [RFC4203] Link Availability Link Protection sub-TLV [RFC4203]
Diversity Support SRLG sub-TLV [RFC4203] Diversity Support SRLG sub-TLV [RFC4203]
Local Adaptation support see above Local Adaptation support See above
Table 1. TE link Attributes in GMPLS OSPF-TE Table 1. TE link attributes in GMPLS OSPF-TE
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 [RFC4205] sub-TLV [RFC4205]
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 [RFC4205] sub-TLV [RFC4205]
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
[RFC4205] [RFC4205]
Link Weight TE Default metric [RFC3784] Link Weight TE Default metric [RFC3784]
Resource Class Administrative Group sub-TLV [RFC3784] Resource Class Administrative Group sub-TLV [RFC3784]
Local Connection Types Switching Capability field part of the Local Connection Types Switching Capability field part of the
Interface Switching Capability Descriptor Interface Switching Capability Descriptor
sub-TLV [RFC4205] sub-TLV [RFC4205]
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] [RFC4205]
Link Availability Link Protection sub-TLV [RFC4205] Link Availability Link Protection sub-TLV [RFC4205]
Diversity Support SRLG sub-TLV [RFC4205] Diversity Support SRLG sub-TLV [RFC4205]
Local Adaptation support see above Local Adaptation support See above
Table 2. TE link Attributes in GMPLS IS-IS-TE
Table 2. TE link attributes in GMPLS IS-IS-TE
Note: Link Attributes represent layer resource capabilities and Note: Link Attributes represent layer resource capabilities and
their utilization i.e. the IGP should be able to advertise these their utilization i.e. the IGP should be able to advertise these
attributes on a per-layer basis. attributes on a per-layer basis.
5.3.2 Node Attributes 5.3.2. Node Attributes
Node attributes are the "Logical Node ID" (described in Section 5.1) Node attributes are the "Logical Node ID" (described in Section 5.1)
and the reachability information described in Section 5.3.3. and the reachability information described in Section 5.3.3.
C.Hopps et al. - Expires January 2006 7 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 an 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,
NODE] is restricted to advertisement of Host addresses and not [OSPF-NODE] is restricted to advertisement of Host addresses and not
prefixes, and therefore requires enhancement (see below). Hence, in prefixes, and therefore it requires enhancement (see below). Thus,
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 a prefix length (that indicates the number of take the form of a prefix length (which indicates the number of
significant bits in the prefix) or a network mask. significant bits in the prefix) or a network mask.
A similar mechanism does not exist for IS-IS. Moreover, the Extended A similar mechanism does not exist for IS-IS. Moreover, the Extended
IP Reachability TLV [RFC3784] focuses on IP reachable end-points IP Reachability TLV [RFC3784] focuses on IP reachable end-points
(terminating points), as its name indicates. (terminating points), as its name indicates.
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 need to be added to the routing Hence, no specific capabilities need to be added to the routing
protocol beyond the ability to locally identify when routing protocol beyond the ability to locally identify when routing
information originates outside of a particular RA. information originates outside of a particular RA.
The methods used for abstraction of routing information are outside The methods used for abstraction of routing information are outside
the scope of GMPLS routing protocols. the scope of GMPLS routing protocols.
5.5 Dissemination of routing information in support of multiple 5.5. Dissemination of Routing Information in Support of Multiple
hierarchical levels of RAs Hierarchal 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 are allowed to redistribute routing information in both RA hierarchy are allowed to redistribute routing information in both
directions between adjacent levels of the hierarchy without any 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
of routing information. routing information.
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 disallows the advertising of routing level hierarchy and disallows the advertising of routing information
information downward in the hierarchy. [RFC2966] defines the up/down downward in the hierarchy. [RFC2966] defines the up/down bit to
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
C.Hopps et al. - Expires January 2006 8
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 has 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 mechanism 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 [RFC2328] prevents inter-area routes (which are learned from OSPFv2 [RFC2328] prevents inter-area routes (which are learned from
area 0) from being passed back to area 0. However, GMPLS makes use of area 0) from being passed back to area 0. However, GMPLS makes use
Type 10 (area-local scope) LSAs to propagate TE information of Type 10 (area-local scope) LSAs to propagate TE information
[RFC3630], [RFC4202]. Type 10 Opaque LSAs are not flooded beyond the [RFC3630], [RFC4202]. Type 10 Opaque LSAs are not flooded beyond the
borders of their associated area. It is therefore necessary to have borders of their associated area. It is therefore necessary to have
a means by which Type 10 Opaque LSA may carry the information that a a means by which Type 10 Opaque LSA may carry the information that a
particular piece of routing information has been learned from a particular piece of routing information has been learned from a
higher level RC when propagated to a lower level RC. Any downward RC higher-level RC when propagated to a lower-level RC. Any downward RC
from this level, which receives an LSA with this information would from this level, which receives an LSA with this information would
omit the information in this LSA and thus not re-introduce this omit the information in this LSA and thus not re-introduce this
information back into a higher level RC. information back into a higher-level RC.
5.6 Routing Protocol Convergence 5.6. Routing Protocol Convergence
Link state protocols have been designed to propagate detected Link state protocols have been designed to propagate detected
topological changes (such as interface failures, link attributes topological changes (such as interface failures and link attributes
modification). The convergence period is short and involves a modification). The convergence period is short and involves a
minimum of routing information exchange. minimum of routing information exchange.
Therefore, existing routing protocol convergence involves mechanisms Therefore, existing routing protocol convergence involves mechanisms
are sufficient for ASON applications. that are sufficient for ASON applications.
5.7 Routing Information Scoping 5.7. Routing Information Scoping
The routing protocol MUST support a single Ri advertising on behalf The routing protocol MUST support a single Ri advertising on behalf
of more than one Li. Since each Li is identified by a unique of more than one Li. Since each Li is identified by a unique TE
TE Router ID, the routing protocol MUST be able to advertise Router ID, the routing protocol MUST be able to advertise multiple TE
multiple TE Router IDs. That is, for [RFC3630], multiple Router Router IDs. That is, for [RFC3630], multiple Router Addresses and
Addresses and for [RFC3784] multiple Traffic Engineering Router Ids. for [RFC3784] multiple Traffic Engineering 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 of multiple Li's creates the following issue, as there is no
longer 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 advertisement
needs to indicate the remote Lj value and rely on the initial
discovery process to 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
C.Hopps et al. - Expires January 2006 9 The Link sub-TLV that is currently part of the top level Link TLV
local Li. Therefore, the routing protocol MUST be able to associates the link to the Router_ID. However, having the Ri
disambiguate the advertised TE links so that they can be associated advertising on behalf of multiple Lis creates the following issue, as
with the correct TE Router ID. there is no longer 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 not
be unique per abstract node (per Li unicity), the advertisement needs
to indicate the remote Lj value and rely on the initial discovery
process to 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 Moreover, when the Ri advertises on behalf multiple Lis, the routing
routing protocol MUST be able to disambiguate the advertised protocol MUST be able to disambiguate the advertised reachability
reachability information (see Section 5.3.3) so that it can be information (see Section 5.3.3) so that it can be associated with the
associated with the correct TE Router ID. correct TE Router ID.
6. Evaluation Scenarios 6. Evaluation Scenarios
The evaluation scenarios are the following; they are respectively The evaluation scenarios are the following; they are respectively
referred to as case 1, 2, 3, and 4. referred to as cases 1, 2, 3, and 4.
In Figure 1, below,
In Figure 1 below:
- 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.
- 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 : : : : | : |
----------------+-----+-----+-----------+-------+---+--+- ----------------+-----+-----+-----------+-------+---+--+-
Data : : : : | : | Data : : : : | : |
Plane -- : -- -- | -- | Plane -- : -- -- | -- |
----|P1|--------|P3|--------|P4|------+-|P5|-+- ----|P1|--------|P3|--------|P4|------+-|P5|-+-
-- \ : / -- -- | -- | -- \ : / -- -- | -- |
\ -- / | | \ -- / | |
|P2| ------ |P2| ------
-- --
Figure 1. Evaluation Case 1, 2 and 3 Figure 1. Evaluation Cases 1, 2, and 3
Case 1 as represented refers either to direct links between edges or Case 1 as represented refers either to direct links between edges or
"logical links" as shown in Figure 2 (or any combination of them) to "logical links" as shown in Figure 2 (or any combination of them).
------ ------ ------ ------
| | | | | | | |
| L1 | | L2 | | L1 | | L2 |
| : | | : | | : | | : |
| : R1| | : R2| | : R1| | : R2|
Control Plane --+--- --+--- Control Plane --+--- --+---
Elements : : Elements : :
------------------+-----------------------------+------------------ ------------------+-----------------------------+------------------
Data Plane : : Data Plane : :
Elements : : Elements : :
----+-----------------------------+----- ----+-----------------------------+-----
C.Hopps et al. - Expires January 2006 10
| : : | | : : |
| --- --- --- | | --- --- --- |
| | |----------| P |----------| | | | | |----------| P |----------| | |
---+--| | --- | |---+--- ---+--| | --- | |---+---
| | | | | | | | | | | |
| | P1|-------------------------| P2| | | | P1|-------------------------| P2| |
| --- --- | | --- --- |
---------------------------------------- ----------------------------------------
Figure 2. Case 1 with Logical Links Figure 2. Case 1 with Logical Links
skipping to change at line 563 skipping to change at page 13, line 24
Data Plane : : Data Plane : :
---:------:--- ---:------:---
|P8 : : | |P8 : : |
| -- -- | | -- -- |
--+-|P |----|P |-+-- --+-|P |----|P |-+--
| -- -- | | -- -- |
-------------- --------------
Figure 3. Case 4: Abstract Node Figure 3. Case 4: Abstract Node
Note: the "signaling function" i.e. the control plane entity that Note: the "signaling function" referred to as Si, i.e., the control
processes the signaling messages (referred to as Si) is not plane entity that processes the signaling messages, is not
represented in these Figures. represented in these figures.
7. Summary of Necessary Additions to OSPF and IS-IS 7. Summary of Necessary Additions to OSPF and IS-IS
The following sections summarize the additions to be provided to The following sections summarize the additions to be provided to OSPF
OSPF and IS-IS in support of ASON routing. and IS-IS in support of ASON routing.
7.1 OSPFv2 7.1. OSPFv2
Reachability Extend Node Attribute sub-TLVs to support Reachability Extend Node Attribute sub-TLVs to support address
address prefixes (see Section 5.3.3) prefixes (see Section 5.3.3).
Link Attributes Representation of cross/inter-layer Link Attributes Representation of cross/inter-layer relationships
relationships in link top-level link TLV (see in link top-level link TLV (see Section 5.3.1).
Section 5.3.1)
C.Hopps et al. - Expires January 2006 11 Optionally, provide for per-signal-type bandwidth
Optionally, provide for per signal-type accounting (see Section 5.3.1).
bandwidth accounting (see Section 5.3.1).
Scoping TE link advertisements to allow for retrieving Scoping TE link advertisements to allow for retrieving
their respective local-remote TE Router_ID their respective local-remote TE Router_ID
relationship(s) (see Section 5.7) relationship(s) (see Section 5.7).
Prefixes part of the reachability Prefixes part of the reachability advertisement
advertisements (using Node Attribute top level (using Node Attribute top-level TLV) needs to be
TLV) needs to be associated to their respective associated to its respective local TE Router_ID
local TE Router_ID (see Section 5.7) (see Section 5.7).
Hierarchy Provide a mechanism by which Type 10 Opaque LSA Hierarchy Provide a mechanism by which Type 10 Opaque LSA may
may carry the information that a particular carry the information that a particular piece of
piece of routing information has been learned routing information has been learned from a
from a higher level RC when propagated to a higher-level RC when propagated to a lower-level RC
lower level RC (such as to not re-introduce this (so as not to re-introduce this information into a
information back into a higher level RC) higher-level RC).
7.2 IS-IS 7.2. IS-IS
Reachability Provide for reachability advertisement (in the Reachability Provide for reachability advertisement (in the form
form of reachable TE prefixes) of reachable TE prefixes).
Link Attributes Representation of cross/inter-layer Link Attributes Representation of cross/inter-layer relationships
relationships in Extended IS Reachability TLV in Extended IS Reachability TLV (see Section
(see Section 5.3.1) 5.3.1).
Optionally, provide for per signal-type Optionally, provide for per-signal-type bandwidth
bandwidth accounting (see Section 5.3.1). accounting (see Section 5.3.1).
Scoping Extended IS Reachability TLVs to allow for Scoping Extended IS Reachability TLVs to allow for
retrieving their respective local-remote TE retrieving their respective local-remote TE
Router_ID relationship(s) (see Section 5.7) Router_ID relationship(s) (see Section 5.7).
Prefixes part of the reachability advertisements Prefixes part of the reachability advertisement
needs to be associated to their respective local needs to be associated to its respective local TE
TE Router_ID (see Section 5.7) Router_ID (see Section 5.7).
Hierarchy Extend the up/down bit mechanisms to propagate Hierarchy Extend the up/down bit mechanisms to propagate the
the summarized topology (see Section 5.3), summarized topology (see Section 5.3) and traffic
traffic engineering information as listed in engineering information as listed in Table 1, as
Table 1, as well as reachability information well as reachability information (see Section
(see Section 5.3.3). 5.3.3).
8. Security Considerations 8. Security Considerations
The introduction of a dynamic control plane to an ASON network The introduction of a dynamic control plane to an ASON network
exposes it to additional security risks that may have been exposes it to additional security risks that may have been controlled
controlled or limited by the use of management plane solutions. The or limited by the use of management plane solutions. The routing
routing protocols play a part in the control plane and may be protocols play a part in the control plane and may be attacked so
that they become unstable or provide incorrect information for use in
C.Hopps et al. - Expires January 2006 12 path computation or by the signaling protocols.
attacked so that they are unstable, or provide incorrect information
for use in path computation or by the signaling protocols.
Nevertheless, there is no reason why the control plane components Nevertheless, there is no reason why the control plane components
cannot be secured, and the security mechanisms developed for the cannot be secured, and the security mechanisms developed for the
routing protocol and used within the Internet are equally applicable routing protocol and used within the Internet are equally applicable
within an ASON context. within an ASON context.
[RFC4258] describes the requirements for security of routing [RFC4258] describes the requirements for security of routing
protocols for the Automatically Switched Optical Network. Reference protocols for the Automatically Switched Optical Network. Reference
is made to [M.3016] that lays out the overall security objectives of is made to [M.3016], which lays out the overall security objectives
confidentiality, integrity, and accountability, and these are well of confidentiality, integrity, and accountability. These are well
discussed for the Internet routing protocols in [THREATS]. discussed for the Internet routing protocols in [THREATS].
A detailed discussion of routing threats and mechanisms, which are A detailed discussion of routing threats and mechanisms that are
currently deployed in operational networks to counter these currently deployed in operational networks to counter these threats
threats, is found in [OPSECPRACTICES]. A detailed listing of the is found in [OPSECPRACTICES]. A detailed listing of the device
device capabilities that can be used to support these practices can capabilities that can be used to support these practices can be found
be found in [RFC3871]. in [RFC3871].
9. IANA Considerations
This draft makes no requests for IANA action.
10. Acknowledgements 9. Acknowledgements
The authors would like to thank Adrian Farrel for having initiated The authors would like to thank Adrian Farrel for having initiated
the proposal of an ASON Routing Solution Design Team and the ITU-T the proposal of an ASON Routing Solution Design Team and the ITU-T
SG15/Q14 for their careful review and input. SG15/Q14 for their careful review and input.
11. References 10. References
11.1 Normative References 10.1. Normative References
[RFC1195] R.Callon, "Use of OSI IS-IS for Routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP
Dual Environments", RFC 1195, December 1990. and dual environments", RFC 1195, December 1990.
[RFC2966] T.Li, T. Przygienda, and H. Smit et al. "Domain-wide [RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide
Prefix Distribution with Two-Level IS-IS", RFC 2966, Prefix Distribution with Two-Level IS-IS", RFC
October 2000. 2966, October 2000.
[RFC2328] J.Moy, "OSPF Version 2", RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "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] Kompella, K. and Y. Rekhter, "Signalling Unnumbered
Resource ReSerVation Protocol - Traffic Engineering Links in Resource ReSerVation Protocol - Traffic
(RSVP-TE)", RFC 3477, January 2003. Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3630] D.Katz et al. "Traffic Engineering (TE) Extensions to [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
OSPF Version 2", RFC 3630, September 2003. Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
C.Hopps et al. - Expires January 2006 13 [RFC3784] Smit, H. and T. Li, "Intermediate System to
[RFC3784] H.Smit and T.Li, "Intermediate System to Intermediate Intermediate System (IS-IS) Extensions for Traffic
System (IS-IS) Extensions for Traffic Engineering (TE)," Engineering (TE)", RFC 3784, June 2004.
RFC 3784, June 2004.
[RFC3871] G.Jones, Ed., "Operational Security Requirements for [RFC3871] Jones, G., Ed., "Operational Security Requirements
Large Internet Service Provider (ISP) IP Network for Large Internet Service Provider (ISP) IP
Infrastructure", RFC 3871, September 2004. Network Infrastructure", RFC 3871, September 2004.
[RFC3946] E.Mannie, and D.Papadimitriou, (Editors) et al., [RFC3946] Mannie, E. and D. Papadimitriou, "Generalized
"Generalized Multi-Protocol Label Switching Extensions Multi-Protocol Label Switching (GMPLS) Extensions
for SONET and SDH Control," RFC 3946, October 2004. for Synchronous Optical Network (SONET) and
Synchronous Digital Hierarchy (SDH) Control", RFC
3946, October 2004.
[RFC4202] K.Kompella (Editor) et al., "Routing Extensions in [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Support of Generalized Multi-Protocol Label Switching Extensions in Support of Generalized Multi-Protocol
(GMPLS)", RFC 4202, October 2005. Label Switching (GMPLS)", RFC 4202, October 2005.
[RFC4203] K.Kompella, Y.Rekhter, et al, "OSPF Extensions in [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF
Support of Generalized Multi-Protocol Label Switching Extensions in Support of Generalized Multi-Protocol
(GMPLS)", RFC 4203, October 2005. Label Switching (GMPLS)", RFC 4203, October 2005.
[RFC4205] K.Kompella, Y.Rekhter, et al, "Intermediate System [RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed.,
to Intermediate System (IS-IS) Extensions in Support "Intermediate System to Intermediate System (IS-IS)
of Generalized Multi-Protocol Label Switching (GMPLS)", Extensions in Support of Generalized Multi-Protocol
RFC 4205, October 2005. Label Switching (GMPLS)", RFC 4205, October 2005.
[RFC4258] D.Brungard et al. "Requirements for Generalized MPLS [RFC4258] Brungard, D., "Requirements for Generalized Multi-
(GMPLS) Routing for Automatically Switched Optical Protocol Label Switching (GMPLS) Routing for the
Network (ASON)," RFC 4258, November 2005. Automatically Switched Optical Network (ASON)", RFC
4258, November 2005.
11.2 Informative References 10.2. Informative References
[RFC4394] D.Fedyk et al., "A Transport Network View of the Link [RFC4394] Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J.,
Management Protocol (LMP)," RFC 4394, February 2006. and D. Papadimitriou, "A Transport Network View of
the Link Management Protocol (LMP)", RFC 4394,
February 2006.
[OPSECPRACTICES] M.Kaeo, "Operational Security Current Practices", [OPSECPRACTICES] Kaeo, M., "Operational Security Current Practices",
Internet Draft (Work in progress), draft-ietf-opsec- Work in Progress, July 2006.
current-practices-02.txt, October 2005.
[OSPF-NODE] R.Aggarwal, and K.Kompella, "Advertising a Router's [OSPF-NODE] Aggarwal, R. and K. Kompella, "Advertising a
Local Addresses in OSPF TE Extensions," Internet Draft, Router's Local Addresses in OSPF TE Extensions",
(work in progress), draft-ietf-ospf-te-node-addr- Work in Progress, June 2006.
02.txt, March 2005.
[THREATS] A.Barbir et al., "Generic Threats to Routing [THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic
Protocols", Internet Draft (work in progress), draft- Threats to Routing Protocols", RFC 4593, October
ietf-rpsec-routing-threats-07.txt, October 2004. 2006.
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
C.Hopps et al. - Expires January 2006 14
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
November 2003. Protocols", 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). June 2006.
11. Author's Addresses
Lyndon Ong (Ciena Corporation)
PO Box 308
Cupertino, CA 95015 , USA
Phone: +1 408 705 2978
EMail: lyong@ciena.com
Dimitri Papadimitriou (Alcatel)
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel.be
Jonathan Sadler
1415 W. Diehl Rd
Naperville, IL 60563
EMail: jonathan.sadler@tellabs.com
Stephen Shew (Nortel Networks)
PO Box 3511 Station C
Ottawa, Ontario, CANADA K1Y 4H7
Phone: +1 613 7632462
EMail: sdshew@nortelnetworks.com
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 15 [M.3016] ITU-T Rec. M.3016.0, "Security for the Management
Plane: Overview", May 2005.
Appendix 1: ASON Terminology Appendix A. ASON Terminology
This document makes use of the following terms: This document makes use of the following terms:
Administrative domain: (see Recommendation G.805) for the purposes of Administrative domain (see Recommendation G.805): For the purposes of
[G7715.1] an administrative domain represents the extent of resources [G.7715.1], an administrative domain represents the extent of
which belong to a single player such as a network operator, a service resources that belong to a single player such as a network operator,
provider, or an end-user. Administrative domains of different players a service provider, or an end-user. Administrative domains of
do not overlap amongst themselves. different players do not overlap amongst themselves.
Control plane: performs the call control and connection control Control plane: Performs the call control and connection control
functions. Through signaling, the control plane sets up and releases functions. Through signaling, the control plane sets up and releases
connections, and may restore a connection in case of a failure. connections and may restore a connection in case of a failure.
(Control) Domain: represents a collection of (control) entities that (Control) Domain: Represents a collection of (control) entities that
are grouped for a particular purpose. The control plane is subdivided are grouped for a particular purpose. The control plane is
into domains matching administrative domains. Within an subdivided into domains matching administrative domains. Within an
administrative domain, further subdivisions of the control plane are administrative domain, further subdivisions of the control plane are
recursively applied. A routing control domain is an abstract entity recursively applied. A routing control domain is an abstract entity
that hides the details of the RC distribution. that hides the details of the RC distribution.
External NNI (E-NNI): interfaces are located between protocol External NNI (E-NNI): Interfaces are located between protocol
controllers between control domains. controllers between control domains.
Internal NNI (I-NNI): interfaces are located between protocol Internal NNI (I-NNI): Interfaces are located between protocol
controllers within control domains. controllers within control domains.
Link: (see Recommendation G.805) a "topological component" which Link (see Recommendation G.805): A "topological component" that
describes a fixed relationship between a "subnetwork" or "access describes a fixed relationship between a "subnetwork" or "access
group" and another "subnetwork" or "access group". Links are not group" and another "subnetwork" or "access group". Links are not
limited to being provided by a single server trail. limited to being provided by a single server trail.
Management plane: performs management functions for the Transport Management plane: Performs management functions for the Transport
Plane, the control plane and the system as a whole. It also provides Plane, the control plane, and the system as a whole. It also
coordination between all the planes. The following management provides coordination between all the planes. The following
functional areas are performed in the management plane: performance, management functional areas are performed in the management plane:
fault, configuration, accounting and security management performance, fault, configuration, accounting, and security
management
Management domain: (see Recommendation G.805) a management domain Management domain (see Recommendation G.805): A management domain
defines a collection of managed objects which are grouped to meet defines a collection of managed objects that are grouped to meet
organizational requirements according to geography, technology, organizational requirements according to geography, technology,
policy or other structure, and for a number of functional areas such policy, or other structure, and for a number of functional areas such
as configuration, security, (FCAPS), for the purpose of providing as fault, configuration, accounting, performance, and security
control in a consistent manner. Management domains can be disjoint, (FCAPS), for the purpose of providing control in a consistent manner.
contained or overlapping. As such the resources within an Management domains can be disjoint, contained, or overlapping. As
administrative domain can be distributed into several possible such, the resources within an administrative domain can be
overlapping management domains. The same resource can therefore distributed into several possible overlapping management domains.
belong to several management domains simultaneously, but a management
domain shall not cross the border of an administrative domain. The same resource can therefore belong to several management domains
simultaneously, but a management 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
C.Hopps et al. - Expires January 2006 16
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.
C.Hopps et al. - Expires January 2006 17 Appendix B. 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): An RA represents a partition of the data plane,
its identifier is used within the control plane as the representation and its identifier is used within the control plane as the
of this partition. Per [G.8080] a RA is defined by a set of sub- representation of this partition. Per [G.8080], an RA is defined by
networks, the links that interconnect them, and the interfaces a set of sub-networks, the links that interconnect them, and the
representing the ends of the links exiting that RA. A RA may contain interfaces representing the ends of the links exiting that RA. An RA
smaller RAs inter-connected by links. The limit of subdivision may contain smaller RAs inter-connected by links. The limit of
results in a RA that contains two sub-networks interconnected by a subdivision results in an RA that contains two sub-networks
single link. interconnected by a single link.
Routing Database (RDB): repository for the local topology, network Routing Database (RDB): Repository for the local topology, network
topology, reachability, and other routing information that is updated topology, reachability, and other routing information that is updated
as part of the routing information exchange and may additionally as part of the routing information exchange and that may additionally
contain information that is configured. The RDB may contain routing contain information that is configured. The RDB may contain routing
information for more than one Routing Area (RA). information for more than one Routing Area (RA).
Routing Components: ASON routing architecture functions. These Routing Components: ASON routing architecture functions. These
functions can be classified as protocol independent (Link Resource functions can be classified as being protocol independent (Link
Manager or LRM, Routing Controller or RC) and protocol specific Resource Manager or LRM, Routing Controller or RC) and protocol
(Protocol Controller or PC). specific (Protocol Controller or PC).
Routing Controller (RC): handles (abstract) information needed for Routing Controller (RC): Handles (abstract) information needed for
routing and the routing information exchange with peering RCs by routing and the routing information exchange with peering RCs by
operating on the RDB. The RC has access to a view of the RDB. The RC operating on the RDB. The RC has access to a view of the RDB. The
is protocol independent. RC is protocol independent.
Note: Since the RDB may contain routing information pertaining to Note: Since the RDB may contain routing information pertaining to
multiple RAs (and possibly to multiple layer networks), the RCs multiple RAs (and possibly to multiple layer networks), the RCs
accessing the RDB may share the routing information. accessing the RDB may share the routing information.
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.
C.Hopps et al. - Expires January 2006 18 Authors' Addresses
Intellectual Property Statement Dimitri Papadimitriou, Ed.
Alcatel
Francis Wellensplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 2408491
EMail: dimitri.papadimitriou@alcatel.be
Lyndon Ong
Ciena Corporation
PO Box 308
Cupertino, CA 95015 , USA
Phone: +1 408 705 2978
EMail: lyong@ciena.com
Jonathan Sadler
Tellabs
1415 W. Diehl Rd
Naperville, IL 60563
EMail: jonathan.sadler@tellabs.com
Stephen Shew
Nortel Networks
3500 Carling Ave.
Ottawa, Ontario, CANADA K2H 8E9
Phone: +1 613 7632462
EMail: sdshew@nortel.com
Dave Ward
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134 USA
Phone: +1-408-526-4000
EMail: dward@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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
to pertain to the implementation or use of the technology described pertain to the implementation or use of the technology described in
in this document or the extent to which any license under such this document or the extent to which any license under such rights
rights might or might not be available; nor does it represent that might or might not be available; nor does it represent that it has
it has made any independent effort to identify any such rights. made any independent effort to identify any such rights. Information
Information on the procedures with respect to rights in RFC on the procedures with respect to rights in RFC documents can be
documents can be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use attempt made to obtain a general license or permission for the use of
of such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository at
at http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
C.Hopps et al. - Expires January 2006 19 Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 167 change blocks. 
457 lines changed or deleted 442 lines changed or added

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