draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt   draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt 
CCAMP Working Group Chris Hopps (Cisco) CCAMP Working Group Chris Hopps (Cisco)
Internet Draft Lyndon Ong (Ciena) Internet Draft Lyndon Ong (Ciena)
Category: Informational Dimitri Papadimitriou (Alcatel) Category: Informational Dimitri Papadimitriou (Alcatel)
Jonathan Sadler (Tellabs) Jonathan Sadler (Tellabs)
Expiration Date: January 2006 Stephen Shew (Nortel) Expiration Date: April 2006 Stephen Shew (Nortel)
Dave Ward (Cisco) Dave Ward (Cisco)
July 2005 October 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-01.txt draft-ietf-ccamp-gmpls-ason-routing-eval-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes 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. 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
skipping to change at line 50 skipping to change at line 50
Copyright (C) The Internet Society (2005). 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).
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.
C.Hopps et al. - Expires April 2006 1
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) Dimitri Papadimitriou (Alcatel, Team Leader and Editor)
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
Chris Hopps (Cisco) Chris Hopps (Cisco)
EMail: chopps@rawdofmt.org EMail: chopps@rawdofmt.org
Lyndon Ong (Ciena Corporation) Lyndon Ong (Ciena Corporation)
skipping to change at line 79 skipping to change at line 80
EMail: sdshew@nortelnetworks.com EMail: sdshew@nortelnetworks.com
Dave Ward (Cisco) Dave Ward (Cisco)
EMail: dward@cisco.com 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].
The reader is expected to be familiar with the terminology introduced
in [ASON-RR].
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
architecture as defined in [G.8080]. architecture as defined in [G.8080].
[ASON-RR] details the routing requirements for the GMPLS routing [ASON-RR] 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
skipping to change at line 103 skipping to change at line 107
these functions is implied. these functions is implied.
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 C.Hopps et al. - Expires January 2006 2
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
skipping to change at line 135 skipping to change at line 137
information is represented and exchanged will vary with the information is represented and exchanged will vary with the
routing protocol used. routing 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 - Processing of routing information exchanged between adjacent
levels of the hierarchy (i.e. Level N+1 and N) including levels of the hierarchy (i.e. Level N+1 and N) including
reachability and upon policy decision summarized topology reachability, and (upon policy decision) summarized topology
information. 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 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 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,
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
C.Hopps et al. - Expires January 2006 3
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
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. BGP
is not considered a candidate protocol mainly because of
- non-support of TE information exchange: each BGP router advertises
only its path to each destination in its vector for loop avoidance,
with no costs or hop counts; each BGP router knows little about
network topology
- 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
that is the route that is advertised.
- BGP is not widely deployed in optical equipment and networks
5.1 Terminology and Identification 5.1 Terminology and Identification
- Pi is a physical node (bearer/data/transport plane) node - Pi is a physical (bearer/data/transport plane) node
- Li is a logical control plane entity that is associated to a - Li is a logical control plane entity that is associated to a
single data plane (abstract) node. The Li is identified by the 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. The latter is a control plane identifier defined as
. RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA follows:
. RFC 3784: Traffic Engineering Router ID TLV (Type 134) . [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 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 document simply states that the use of the TE Router ID to
the Li. Other documents (the referenced RFC 3630 and RFC identify Li. [RFC 3630] and [RFC3784] provide the definitions.
3784) 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 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-RR], 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 except that the Ri may have be in a particular entity relationship except that the Ri may have
C.Hopps et al. - Expires January 2006 4
multiple Li in its scope. The relationship between Ri and Li is 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 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 Li's.
Thus, the routing protocol MUST be able to advertise multiple TE Thus, the routing protocol MUST be able to advertise multiple TE
Router IDs. Router IDs (see Section 5.7).
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. This document does not assume any specific constraint on or more Li. 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 signaling function, and issues of control plane accessibility for signaling function, and
makes no assumptions about how control plane accessibility to the Si makes no assumptions about how control plane accessibility to the Si
is achieved. 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 without further modification.
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 a single hierarchical level.
Routing information mapping between levels may require specific Routing information mapping between levels require specific
guidelines. processing (see Section 5.5).
The control plane does not transport Pi information 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 [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) that 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 "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 "1.1.1.1"). The mapping Li/Pi is kept "666B.F999.AF10.222C" but only "192.0.2.1"). The mapping Li/Pi is
local. So, when the Si receives a control plane message requesting kept local. So, when the Si receives a control plane message
the use of "1.1.1.1", Si knows locally that this information refers requesting the use of "192.0.2.1", Si knows locally that this
to the data plane entity identified by the transport plane information refers to the data plane entity identified by the
identifier "666B.F999.AF10.222C". transport plane identifier "666B.F999.AF10.222C".
Note also that the Li and Pi addressing spaces may be identical.
C.Hopps et al. - Expires January 2006 5
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; note that these identifiers
may either be 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 the engineering, [RFC 3477] RECOMMENDS that the Li value (referred to
"LSR Router ID") to be set to the TE Router ID value. the "LSR Router ID") to be set to the TE Router ID value.
C.Hopps et al. - Expires January 2006 5 OSPF and IS-IS therefore carry sufficient node identification
information without further modification.
5.3.1 Link Attributes 5.3.1 Link Attributes
From the list of link attributes and characteristics (detailed in [ASON-RR] provides a list of link attributes and characteristics
[ASON-RR], the Local Adaptation support information is missing as TE that need to be advertised by a routing protocol. All TE link
link attribute. GMPLS routing does not currently consider the use of attributes and characteristics are currently handled by OSPF and IS-
IS (see Table 1) with the exception of Local Adaptation support.
Indeed, 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.
currently covered (see Table 1.)
However, the representation of bandwidth requires further analysis In addition, the representation of bandwidth requires further
i.e. GMPLS Routing defines an Interface Switching Capability consideration. Indeed, GMPLS Routing defines an Interface Switching
Descriptor (ISCD) that delivers information about the (maximum/ Capability Descriptor (ISCD) that delivers information about the
minimum) bandwidth per priority an LSP can make use of. In the ASON (maximum/ minimum) bandwidth per priority of which an LSP can make
context, other representations are possible, e.g., in terms of a set use. This information is usually used in combination with the
of tuples <signal_type; number of unallocated timeslots>. The latter Unreserved Bandwidth sub-TLV that provides the amount of bandwidth
also may require definition of additional signal types (from those not yet reserved on a TE link.
defined in [RFC 3496]) to represent contiguous concatenation i.e.
STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
The method proposed in [GMPLS-RTG] is the most straightforward In the ASON context, other bandwidth accounting representations are
without requiring any bandwidth accounting change from an LSR possible, e.g., in terms of a set of tuples <signal_type; number of
perspective. However, it introduces some lost of information. This unallocated timeslots>. The latter representation may also require
lost of information affects the number of signals that can be used definition of additional signal types (from those defined in
but not the range they cover. On the other hand, if additional [RFC3946]) to represent support of contiguously concatenated signals
technology specific information (such as capabilities) are i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.
advertised a finer grained resource countdown and accounting can be
performed allowing for network wide resource allocation in Sonet/SDH However, the method proposed in [RFC4202] is the most
environments. straightforward without requiring any bandwidth accounting change
from an LSR perspective (in particular, when the ISCD sub-TLV
information is combined with the information provided by the
Unreserved Bandwidth 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 [GMPLS-OSPF] sub-TLV [RFC4203]
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-OSPF] sub-TLV [RFC4203]
C.Hopps et al. - Expires January 2006 6
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-OSPF] [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 [GMPLS-OSPF] 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
[GMPLS-OSPF] [RFC4203]
Link Availability Link Protection sub-TLV [GMPLS-OSPF] Link Availability Link Protection sub-TLV [RFC4203]
Diversity Support SRLG sub-TLV [GMPLS-OSPF] Diversity Support SRLG sub-TLV [RFC4203]
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 [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 [GMPLS-ISIS] 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
[GMPLS-ISIS] [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 [GMPLS-ISIS] 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] [GMPLS-ISIS]
Link Availability Link Protection sub-TLV [GMPLS-ISIS] Link Availability Link Protection sub-TLV [RFC4205]
Diversity Support SRLG sub-TLV [GMPLS-ISIS] Diversity Support SRLG sub-TLV [RFC4205]
Local Adaptation support see above Local Adaptation support see above
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 Note: Link Attributes represent layer resource capabilities and
their utilization. their utilization i.e. the IGP should be able to advertise these
attributes on a per-layer basis.
5.3.2 Node Attributes 5.3.2 Node Attributes
Nodes attributes include the "Logical Node ID" (as detailed in Nodes attributes are the "Logical Node ID" (as detailed in Section
Section 5.1) and the reachability information as described in 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
C.Hopps et al. - Expires January 2006 7
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, [OSPF-
NODE] restricts to advertisement of Host addresses and not prefixes, NODE] is restricted to advertisement of Host addresses and not
and therefore requires enhancement (see below). prefixes, and therefore requires enhancement (see below). Hence, in
order to advertise blocks of reachable address prefixes a
A similar mechanism does not exist for IS-IS as the Extended IP
Reachability TLV [RFC3784] focuses on IP reachable end-points
(terminating points), as its name indicates.
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 a 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 A similar mechanism does not exist for IS-IS. Moreover, the Extended
IP Reachability TLV [RFC3784] focuses on IP reachable end-points
(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 are added to the routing protocol hence no specific capabilities need to be added to the routing
beyond the ability to locally identify when routing information protocol beyond the ability to locally identify when routing
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 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.
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 disallows the advertising of routing
downward in the hierarchy. [RFC2966] defines the up/down bit to information downward in the hierarchy. [RFC2966] defines the up/down
allow advertising downward in the hierarchy the "IP Internal bit to 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.
C.Hopps et al. - Expires January 2006 8
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 prevents that inter-area routes, which are learned from area OSPFv2 [RFC2328] prevents inter-area routes (which are learned from
0 are not passed back to area 0. However, GMPLS makes use of Type 10 area 0) from being passed back to area 0. However, GMPLS makes use of
(area-local scope) LSA to propagate TE information [RFC3630], [GMPLS- Type 10 (area-local scope) LSAs to propagate TE information
RTG]. Type 10 Opaque LSAs are not flooded beyond the borders of [RFC3630], [RFC4202]. Type 10 Opaque LSAs are not flooded beyond the
their associated area. It is therefore necessary to have a means by borders of their associated area. It is therefore necessary to have
which Type 10 Opaque LSA may carry the information that particular a means by which Type 10 Opaque LSA may carry the information that a
routing information has been learned from a higher level RC when particular piece of routing information has been learned from a
higher level RC when propagated to a lower level RC. Any downward RC
C.Hopps et al. - Expires January 2006 8 from this level, which receives an LSA with this information would
propagated to a lower level RC. Any downward RC from this level, omit the information in this LSA and thus not re-introduce this
which receives an LSA with this information would omit the information back into a higher level RC.
information in this LSA and thus not re-introduce this information
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 propagate detected
changes (such as interface failures, link attributes modification). topological changes (such as interface failures, link attributes
Convergence period is short and involves a minimum of routing modification). The convergence period is short and involves a
information exchange. minimum of routing information exchange.
Therefore, existing routing protocol convergence mechanisms are Therefore, existing routing protocol convergence involves mechanisms
sufficient for ASON applications. 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 Router ID, the routing protocol MUST be able to advertise TE Router ID, the routing protocol MUST be able to advertise
multiple TE Router IDs. multiple TE Router IDs. That is for [RFC3630] multiple Router
Addresses and for [RFC3784] multiple Traffic Engineering Router Ids.
The Link sub-TLV currently part of the top level Link TLV associates 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 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 behalf multiple Li's creates the following issue as there is no
a 1:1 relationship between the Router_ID and the TE Router_ID but a longer a 1:1 relationship between the Router_ID and the TE Router_ID
1:N relationship is possible (see Section 5.1). As the link local but a 1:N relationship is possible (see Section 5.1). As the link
and link remote (unnumbered) ID association may be not unique per local and link remote (unnumbered) ID association may be not unique
abstract node (per Li unicity), the TE link advertisement needs to per abstract node (per Li unicity), the advertisement needs to
additionally indicate the remote Lj value such as to unambiguously indicate the remote Lj value and rely on the initial discovery
retrieve the [Li;Lj] relationship(s). In brief, as unnumbered links process to retrieve the {Li;Lj} relationship(s). In brief, as
have their ID defined on per Li bases, the remote Lj needs to be unnumbered links have their ID defined on per Li bases, the remote
identified to scope the link remote ID to the local Li. Therefore, Lj needs to be identified to scope the link remote ID to the local
the routing protocol MUST be able to disambiguate the advertised TE Li. Therefore, the routing protocol MUST be able to disambiguate the
links so that they can be associated with the correct TE Router ID. advertised TE links so that they can be associated with the correct
TE Router ID.
C.Hopps et al. - Expires January 2006 9
Moreover, when the Ri advertises on behalf multiple Li's, the Moreover, when the Ri advertises on behalf multiple Li's, the
routing protocol MUST be able to disambiguate the advertised routing protocol MUST be able to disambiguate the advertised
reachability information (see Section 5.3.3) so that it can be reachability information (see Section 5.3.3) so that it can be
associated with the correct TE Router ID. 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; they are respectively
respectively case 1), 2), 3) and 4). Additional base scenarios referred to as case 1, 2, 3, and 4.
(being not combinations or decomposition of entities) may further
complete this set in a future revision of this document.
In the below Figure 1: 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
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 : : : : | : |
----------------+-----+-----+-----------+-------+---+--+- ----------------+-----+-----+-----------+-------+---+--+-
Data : : : : | : | Data : : : : | : |
Plane -- : -- -- | -- | Plane -- : -- -- | -- |
----|P1|--------|P3|--------|P4|------+-|P5|-+- ----|P1|--------|P3|--------|P4|------+-|P5|-+-
-- \ : / -- -- | -- | -- \ : / -- -- | -- |
\ -- / | | \ -- / | |
|P2| ------ |P2| ------
-- --
Case 1) as represented refers either to direct links between edges Figure 1. Evaluation Case 1, 2 and 3
or "logical links" as per below figure (or any combination of them)
Case 1 as represented refers either to direct links between edges or
"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 : :
----+-----------------------------+----- ----+-----------------------------+-----
| : : | | : : |
| --- --- --- | | --- --- --- |
| | |----------| P |----------| | | | | |----------| P |----------| | |
C.Hopps et al. - Expires January 2006 10
---+--| | --- | |---+--- ---+--| | --- | |---+---
| | | | | | | | | | | |
| | P1|-------------------------| P2| | | | P1|-------------------------| P2| |
| --- --- | | --- --- |
---------------------------------------- ----------------------------------------
Figure 2. Case 1 with Logical Links
Another case (referred to as Case 4) is constituted by the Abstract Another case (referred to as Case 4) is constituted by the Abstract
Node as represented in the below figure. There is no internal Node as represented in Figure 3. There is no internal structure
structure associated (externally) to the abstract node. associated (externally) to the abstract node.
-------------- --------------
|R4 | |R4 |
| | | |
| L6 | | L6 |
| : | | : |
| ...... | | ...... |
C.Hopps et al. - Expires January 2006 10
---:------:--- ---:------:---
Control Plane : : Control Plane : :
+------+------+------+ +------+------+------+
Data Plane : : Data Plane : :
---:------:--- ---:------:---
|P8 : : | |P8 : : |
| -- -- | | -- -- |
--+-|P |----|P |-+-- --+-|P |----|P |-+--
| -- -- | | -- -- |
-------------- --------------
Figure 3. Case 4: Abstract Node
Note: the "signaling function" i.e. the control plane entity that Note: the "signaling function" i.e. the control plane entity that
processes the signaling messages (referred to as Si) is not processes the signaling messages (referred to as Si) is not
represented in these Figures. More than one Si can be associated to represented in these Figures.
one Ri (N:1 relationship, N >= 1) and make use of the path
computation function associated to the Ri.
7. Acknowledgements 7. Summary of Necessary Additions to OSPF and IS-IS
The following sections summarize the additions to be provided to
OSPF and IS-IS in support of ASON routing
7.1 OSPFv2
Reachability Extend Node Attribute sub-TLVs to support
address prefixes (see Section 5.3.3)
Link Attributes Representation of cross/inter-layer
relationships in link top-level link TLV (see
Section 5.3.1)
Optionally, provide for per signal-type
bandwidth accounting (see Section 5.3.1).
C.Hopps et al. - Expires January 2006 11
Scoping TE link advertisements to allow for retrieving
their respective local-remote TE Router_ID
relationship(s) (see Section 5.7)
Prefixes part of the reachability
advertisements (using Node Attribute top level
TLV) needs to be associated to their respective
local TE Router_ID (see Section 5.7)
Hierarchy Provide a mechanism by which Type 10 Opaque LSA
may carry the information that a particular
piece of routing information has been learned
from a higher level RC when propagated to a
lower level RC (such as to not re-introduce this
information back into a higher level RC)
7.2 IS-IS
Reachability Provide for reachability advertisement (in the
form of reachable TE prefixes)
Link Attributes Representation of cross/inter-layer
relationships in Extended IS Reachability TLV
(see Section 5.3.1)
Optionally, provide for per signal-type
bandwidth accounting (see Section 5.3.1).
Scoping Extended IS Reachability TLVs to allow for
retrieving their respective local-remote TE
Router_ID relationship(s) (see Section 5.7)
Prefixes part of the reachability advertisements
needs to be associated to their respective local
TE Router_ID (see Section 5.7)
Hierarchy Extend the up/down bit mechanisms to propagate
the summarized topology (see Section 5.3),
traffic engineering information as listed in
Table 1, as well as reachability information
(see Section 5.3.3).
8. 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.
8. References 9. References
8.1 Normative References 9.1 Normative References
[GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in C.Hopps et al. - Expires January 2006 12
Support of Generalized MPLS," Internet Draft (work in [ASON-RR] W.Alanqar et al. "Requirements for Generalized MPLS
progress), draft-ietf-ccamp-gmpls-routing-09.txt, (GMPLS) Routing for Automatically Switched Optical
October 2003. Network (ASON)," Work in progress, draft-ietf-ccamp-
gmpls-ason-routing-reqts-05.txt, October 2004.
[LMP-T] D.Fedyk et al., "A Transport Network View of LMP," [RFC1195] R.Callon, "Use of OSI IS-IS for Routing in TCP/IP and
Internet Draft (work in progress), draft-ietf-ccamp- Dual Environments", RFC 1195, December 1990.
transport-lmp-02, May 2005.
[OSPF-NODE] R.Aggarwal, and K.Kompella, "Advertising a Router's [RFC2966] T.Li, T. Przygienda, and H. Smit et al. "Domain-wide
Local Addresses in OSPF TE Extensions," Internet Draft, Prefix Distribution with Two-Level IS-IS", RFC 2966,
(work in progress), draft-ietf-ospf-te-node-addr- October 2000.
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.
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,
RFC 3667, February 2004.
[RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF
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
System (IS-IS) Extensions for Traffic Engineering (TE)," System (IS-IS) Extensions for Traffic Engineering (TE),"
RFC 3784, June 2004. RFC 3784, June 2004.
[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 [RFC4202] Kompella, K. (Editor) et al., "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005.
[ASON-RR] W.Alanqar et al. "Requirements for Generalized MPLS [RFC4203] K. Kompella, Y. Rekhter, et al, "OSPF Extensions in
(GMPLS) Routing for Automatically Switched Optical Support of Generalized Multi-Protocol Label Switching
Network (ASON)," Work in progress, draft-ietf-ccamp- (GMPLS)", RFC 4203, October 2005.
gmpls-ason-routing-reqts-05.txt, October 2004.
[RFC4205] K. Kompella, Y. Rekhter, et al, "Intermediate System
to Intermediate System (IS-IS) Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4205, October 2005.
9.2 Informative References
C.Hopps et al. - Expires January 2006 13
[LMP-T] D.Fedyk et al., "A Transport Network View of LMP,"
Internet Draft (work in progress), draft-ietf-ccamp-
transport-lmp-02, May 2005.
[OSPF-NODE] R.Aggarwal, and K.Kompella, "Advertising a Router's
Local Addresses in OSPF TE Extensions," Internet Draft,
(work in progress), draft-ietf-ospf-te-node-addr-
02.txt, March 2005.
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 10. 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
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
Dave Ward (Cisco Systems) Dave Ward (Cisco Systems)
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134 USA San Jose, CA 95134 USA
C.Hopps et al. - Expires January 2006 14
Phone: +1-408-526-4000 Phone: +1-408-526-4000
EMail: dward@cisco.com EMail: dward@cisco.com
C.Hopps et al. - Expires January 2006 13 C.Hopps et al. - Expires January 2006 15
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 712 skipping to change at line 804
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
C.Hopps et al. - Expires January 2006 14 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 15 C.Hopps et al. - Expires January 2006 17
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 777 skipping to change at line 869
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 16 C.Hopps et al. - Expires January 2006 18
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 824 skipping to change at line 916
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.
C.Hopps et al. - Expires January 2006 17 C.Hopps et al. - Expires January 2006 19
 End of changes. 89 change blocks. 
177 lines changed or deleted 269 lines changed or added

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