draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt   draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt 
CCAMP Working Group Wesam Alanqar (Sprint) CCAMP Working Group Wesam Alanqar (Sprint)
Internet Draft Deborah Brungard (ATT) Internet Draft Deborah Brungard (ATT)
Category: Informational Dave Meyer (Cisco Systems) Category: Informational David Meyer (Cisco Systems)
Lyndon Ong (Ciena) Lyndon Ong (Ciena)
Expiration Date: July 2004 Dimitri Papadimitriou (Alcatel) Expiration Date: October 2004 Dimitri Papadimitriou (Alcatel)
Jonathan Sadler (Tellabs) Jonathan Sadler (Tellabs)
Stephen Shew (Nortel) Stephen Shew (Nortel)
February 2004 April 2004
Requirements for Generalized MPLS (GMPLS) Routing Requirements for Generalized MPLS (GMPLS) Routing
for Automatically Switched Optical Network (ASON) for Automatically Switched Optical Network (ASON)
draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC-2026. all provisions of Section 10 of RFC-2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
skipping to change at line 49 skipping to change at line 48
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).
This document concentrates on the routing requirements on the GMPLS This document concentrates on the routing requirements on the GMPLS
suite of protocols to support the capabilities and functionalities suite of protocols to support the capabilities and functionalities
for an Automatically Switched Optical Network (ASON) as defined by for an Automatically Switched Optical Network (ASON) as defined by
ITU-T. ITU-T.
W.Alanqar et al. - Expires July 2004 1 W.Alanqar et al. - Expires September 2004 1
Table of Contents
Status of this Memo .............................................. 1
Abstract ......................................................... 1
1. Contributors .................................................. 2
2. Conventions used in this document ............................. 2
3. Introduction .................................................. 2
4. ASON Routing Architecture and Requirements .................... 4
4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) ..... 5
4.2 Hierarchical Routing Information Dissemination ............... 5
4.3 Configuration ................................................ 7
4.3.1 Configuring the Multi-Level Hierarchy ...................... 7
4.3.2 Configuring RC Adjacencies ................................. 7
4.4 Evolution .................................................... 7
4.5 Routing Attributes ........................................... 8
4.5.1 Taxonomy of Routing Attributes ............................. 8
4.5.2 Commonly Advertised Information ............................ 9
4.5.3 Node Attributes ............................................ 9
4.5.4 Link Attributes ............................................ 9
5. Security Considerations ...................................... 11
6. Conclusions .................................................. 11
7. Acknowledgements ............................................. 13
8. Intellectual Property Considerations ......................... 13
8.1 IPR Disclosure Acknowledgement .............................. 13
9. References ................................................... 14
9.1 Normative References ........................................ 14
10. Author's Addresses .......................................... 14
Appendix 1: ASON Terminology .................................... 16
Appendix 2: ASON Routing Terminology ............................ 18
Full Copyright Statement ........................................ 19
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
Requirements design team joint effort. Requirements design team joint effort.
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119. this document are to be interpreted as described in RFC 2119
[RFC2119].
3. Introduction 3. Introduction
The GMPLS suite of protocols provides among other capability support The GMPLS suite of protocols provides among other capabilities
for controlling different switching technologies. These include support for controlling different switching technologies. These
support for requesting TDM connections utilizing SONET/SDH (see ANSI include support for requesting TDM connections utilizing SONET/SDH
T1.105/ITU-T G.707) as well as Optical Transport Networks (see ITU-T (see ANSI T1.105/ITU-T G.707) as well as Optical Transport Networks
G.709). However, there are certain capabilities that are needed to (OTN, see ITU-T G.709). However, there are certain capabilities that
support the ITU-T G.8080 control plane architecture for the are needed to support the ITU-T G.8080 control plane architecture
Automatically Switched Optical Network (ASON). Therefore, it is for Automatically Switched Optical Network (ASON). Therefore, it is
W.Alanqar et al. - Expires October 2004 2
desirable to understand the corresponding requirements for the GMPLS desirable to understand the corresponding requirements for the GMPLS
protocol suite. The ASON control plane architecture is defined in protocol suite. The ASON control plane architecture is defined in
[G.8080] and ASON routing requirements are identified in [G.7715] [G.8080], ASON routing requirements are identified in [G.7715], and
and refined in [G.7715.1] for link state architectures. These in [G.7715.1] for ASON link state protocols. These Recommendations
recommendations provide functional requirements and architecture, apply to all G.805 layer networks (e.g. SDH and OTN), and provide
they provide a protocol neutral approach. protocol neutral functional requirements and architecture.
This document focuses on the routing requirements for the GMPLS This document focuses on the routing requirements for the GMPLS
suite of protocols to support the capabilities and functionality of suite of protocols to support the capabilities and functionality of
ASON control planes. It discusses the requirements for GMPLS routing ASON control planes. This document summarizes the ASON requirements
that MAY subsequently lead to additional backward compatible using ASON terminology. This document does not address GMPLS
extensions to support the capabilities specified in the above applicability or GMPLS capabilities. Any protocol (in particular,
referenced documents. A description of backward compatibility routing) applicability, design or suggested extensions is strictly
considerations is provided in Section 5. Nonetheless, any protocol outside the scope of this document. ASON (Routing) terminology
(in particular, routing) design or suggested protocol extensions is sections are provided in Appendix 1 and 2.
strictly outside the scope of this document. An ASON (Routing)
terminology section is provided in Appendix 1 and Appendix 2.
The ASON model distinguishes reference points (representing points The ASON routing architecture is based on the following assumptions:
of information exchange) defined (1) between an administrative - A network is subdivided based on operator decision and criteria
domain and a user (user-network interface or UNI), (2) between (e.g. geography, administration, and/or technology), the network
administrative domains or within an administrative domain between subdivisions are defined in ASON as Routing Areas (RAs).
different control domains (external network-network interface or E- - The routing architecture and protocols applied after the network
NNI) and, (3) within the same administrative domain between control is subdivided is an operator's choice. A multi-level hierarchy of
components (or simply controllers) of the same control domain RAs, as defined in ITU-T [G.7715] and [G.7715.1], provides for a
(internal network-network interface or I-NNI). The ASON model allows hierarchical relationship of RAs based on containment, i.e. child
for the protocols used within different control domains to be RAs are always contained within a parent RA. The hierarchical
different; and for the protocol used between control domains to be containment relationship of RAs provides for routing information
different than the protocols used within control domains. I-NNI abstraction, thereby enabling scalable routing information
control interfaces are located between protocol controllers within a representation. The maximum number of hierarchical RA levels to be
control domain. E-NNI control interfaces are located on protocol supported is NOT specified (outside the scope).
controllers between control domains. - Within an ASON RA and for each level of the routing hierarchy,
multiple routing paradigms (hierarchical, step- by-step, source-
based), centralized or distributed path computation, and multiple
different routing protocols MAY be supported. The architecture
does NOT assume a one-to-one correspondence of a routing protocol
and a RA level and allows the routing protocol(s) used within
different RAs (including child and parent RAs) to be different.
The realization of the routing paradigm(s) to support the
hierarchical levels of RAs is NOT specified.
- The routing adjacency topology (i.e. the associated Protocol
Controller (PC) connectivity) and transport topology is NOT
assumed to be congruent.
- The requirements support architectural evolution, e.g. a change in
the number of RA levels, as well as aggregation and segmentation
of RAs.
W.Alanqar et al. - Expires July 2004 2 The description of the ASON routing architecture provides for a
The term routing information refers to the abstract representation conceptual reference architecture, with definition of functional
of network routing related information such as node and link components and common information elements to enable end-to-end
attributes (see Section 4.5). No routing information is passed over routing in the case of protocol heterogeneity and facilitate
the UNI. Routing information exchanged over the NNI is subject to management of ASON networks. This description is only conceptual: no
the policy constraints at individual NNIs. The routing information physical partitioning of these functions is implied.
exchanged over the E-NNI encapsulates the common semantics of the
individual domain information while allowing different
representation within each domain.
The ASON routing architecture is based on the following assumptions: W.Alanqar et al. - Expires October 2004 3
- A carrier's network is subdivided as Routing Areas (RAs). Each RA
shall be uniquely identifiable within a carrier's network (i.e.
administrative domain). RAs partitioning provide for routing
information abstraction, thereby enabling scalable routing.
- Routing Controllers (RC) provide for the exchange of routing
information between and within a RA. The routing information
exchanged between RCs is subject to policy constraints imposed at
reference points (E-NNI and I-NNI).
- For a RA, the set of RCs is referred to as a routing (control)
domain. The RC MAY support more than one routing protocol (i.e. an
RC MAY support multiple Protocol Controller (PCs)). There SHOULD
NOT be any dependencies on the different routing protocols used.
- The routing information exchanged between routing domains (i.e.
inter-domain) is independent of both the intra-domain routing
protocol and the intra-domain control distribution choice(s), e.g.
centralized, fully distributed.
- The routing adjacency topology (i.e. the associated PC
connectivity topology) and the transport network topology SHALL
NOT be assumed to be congruent.
The following functionality is expected from GMPLS routing to 4. ASON Routing Architecture and Requirements
instantiate ASON routing realization (see [G.7715] and [G.7715.1]):
- support multiple hierarchical levels of RAs; the number of
hierarchical levels to be supported is routing protocol
implementation specific.
- support hierarchical routing information dissemination including
summarized routing information
- support for multiple links between nodes (and between RAs) and for
link and node diversity
- support architectural evolution in terms of the number of levels
of hierarchies, aggregation and segmentation of RAs
- support routing information based on a common set of information
elements as defined in [G.7715] and [G.7715.1], divided between
attributes pertaining to links and abstract nodes (each
representing either a sub-network or simply a node). [G.7715]
recognizes that the manner in which the routing information is
represented and exchanged will vary with the routing protocol
used.
Also, the behaviour of GMPLS routing is expected to be such that: The fundamental architectural concept is the RA and it's related
- it is scalable with respect to the number of links, nodes and RAs functional components (see Appendix 2 on terminology). The routing
- in response to a routing event (e.g. topology update, reachability services offered by a RA are provided by a Routing Performer (RP).
An RP is responsible for a single RA, and it MAY be functionally
realized using distributed Routing Controllers (RC). The RC, itself,
MAY be implemented as a cluster of distributed entities (ASON refers
to the cluster as a Routing Control Domain (RCD)). The RC components
for a RA receive routing topology information from their associated
Link Resource Manager(s) (LRMs) and store this information in the
Routing Information Database (RDB). The RDB is replicated at each RC
bounded to the same Routing Area (RA), and MAY contain information
about multiple transport plane network layers. Whenever the routing
topology changes, the LRM informs the corresponding RC, which in
turn updates its associated RDB. In order to assure RDB
synchronization, the RCs co-operate and exchange routing
information. Path computation functions MAY exist in each RC, MAY
exist on selected RCs within the same RA, or MAY be centralized for
the RA.
W.Alanqar et al. - Expires July 2004 3 In this context, communication between RCs within the same RA is
update), it delivers convergence and damping against flapping realized using a particular routing protocol (or multiple
- it fulfils the operational security objectives where required protocols). In ASON, the communication component is represented by
the protocol controller (PC) component(s) and the protocol messages
are conveyed over the ASON control plane's Signaling Control Network
(SCN). The PC MAY convey information for one or more transport
network layers (refer to Section 4.2 Note). The RC is protocol
independent and RC communications MAY be realized by multiple,
different PCs within a RA.
4. ASON Requirements for GMPLS Routing The ASON routing architecture defines a multi-level routing
hierarchy of RAs based on a containment model to support routing
information abstraction. [G.7715.1] defines the ASON hierarchical
link state routing protocol requirements for communication of
routing information within an RA (one level) to support hierarchical
routing information dissemination (including summarized routing
information for other levels). The Communication between any of the
other functional component(s) (e.g. SCN, LRM, and between RCDs (RC-
RC communication between RAs)), is outside the scope of [G.7715.1]
protocol requirements and, thus, is also outside the scope of this
document.
The description of the ASON routing components (see Appendix 2) is ASON Routing components are identified by identifiers that are drawn
provided in terms of routing functionality. This description is only from different name spaces (see [G.7715.1]). These are control plane
conceptual: no physical partitioning of these functions is implied. identifiers for transport resources, components, and SCN addresses.
The formats of those identifiers in a routing protocol realization
SHALL be implementation specific and outside the scope of this
document.
The Routing Controller (RC) components receive routing information The failure of a RC, or the failure of communications between RCs,
from their associated Link Resource Manager(s) (LRMs) regarding TE and the subsequent recover from the failure condition MUST NOT
links and store this information in the Routing Information Database
(RDB). The RDB is replicated at each RC within the same Routing Area
(RA), and MAY contain information about multiple transport plane
network layers. Whenever the state of a TE link (or component link)
changes, the LRM informs the corresponding RC, which in turn updates
its associated RDB. In order to assure RDB synchronization, the RCs
co-operate and exchange routing information. In this context,
communication between RCs is realized using a particular routing
protocol represented by the protocol controller (PC) component and
the protocol messages are conveyed over the Signaling Control
Network (SCN). The PC MAY convey information for one or more
transport network layers. Moreover, as [G7715.1] states and
illustrates in its Figure 1, ASON routing protocol requirements
deals exclusively with the PC to PC communication of the (RC)
routing information; therefore any other communication between any
other functional component(s) (e.g. SC, LRM) is also outside the
scope of this document.
Note: the RC can be thought of as the function processing the TE W.Alanqar et al. - Expires October 2004 4
database populated by the link local/remote component and TE links disrupt calls in progress and their associated connections. Calls
(LRM) and by the network wide TE links through the PC which being set up MAY fail to complete, and the call setup service MAY be
processes the protocol specific routing exchanges. The SCN unavailable during recovery actions.
corresponds to the IP control plane topology enabling routing
exchanges between GMPLS controllers (i.e. the routing adjacencies).
4.1 Multiple Hierarchical Levels 4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs)
[G.8080] introduces the concept of Routing Area (RA). RAs provide [G.8080] introduces the concept of Routing Area (RA) in reference to
for routing information abstraction, thereby enabling scalable a network subdivision. RAs provide for routing information
routing information representation. Except for the single RA case, abstraction. Except for the single RA case, RAs are hierarchically
RAs are hierarchically contained: a higher level (parent) RA contained: a higher level (parent) RA contains lower level (child)
contains lower level (child) RAs that in turn MAY also contain RAs, RAs that in turn MAY also contain RAs, etc. Thus, RAs contain RAs
etc. Thus, RAs contain RAs that recursively define successive that recursively define successive hierarchical RA levels.
hierarchical routing levels.
However, the RA containment relationship describes only an However, the RA containment relationship describes only an
architectural hierarchical organization of RAs. It does not restrict architectural hierarchical organization of RAs. It does not restrict
the routing protocol realization (e.g. OSPF multi-areas, path a specific routing protocol's realization (e.g. OSPF multi-areas,
computation, etc.). Moreover, the realization of the routing path computation, etc.). Moreover, the realization of the routing
paradigm to support hierarchical routing and the number of paradigm to support a hierarchical organization of RAs and the
number of hierarchical RA levels to be supported is routing protocol
W.Alanqar et al. - Expires July 2004 4
hierarchical levels to be supported is routing protocol specific and
outside the scope of this document.
ASON routing components are identified by values that MAY be drawn
from several identifier spaces (see [G.7715.1]). The use of
identifiers in a routing protocol realization is implementation
specific and outside the scope of this document. specific and outside the scope of this document.
In a multi-level routing hierarchy, it is necessary to distinguish In a multi-level hierarchy of RAs, it is necessary to distinguish
among RCs within a level and RCs at different levels of the routing among RCs for the different levels of the RA hierarchy. Before any
hierarchy. Before any pair of RCs establishes communication, they pair of RCs establishes communication, they MUST verify they are
MUST verify they belong to the same RA (see Section 4.2). A RA bounded to the same parent RA (see Section 4.2). A RA identifier (RA
identifier (RA ID) is required to provide the scope within which the ID) is required to provide the scope within which the RCs can
RCs can communicate. To distinguish between RCs within the same RA, communicate. To distinguish between RCs bounded to the same RA, an
an RC identifier (RC ID) is required; the RC ID must be unique RC identifier (RC ID) is required; the RC ID MUST be unique within
within its containing RA. its containing RA.
A RA represents a partition of the data plane and its identifier A RA represents a partition of the data plane and its identifier
(i.e. RA ID) is used within the control plane as a reference to the (i.e. RA ID) is used within the control plane as a reference to the
data plane partition. RA IDs MAY be associated with a transport data plane partition. Each RA SHALL be uniquely identifiable within
plane name space whereas RC IDs are associated with a control plane a carrier's network. RA IDs MAY be associated with a transport plane
name space. name space whereas RC IDs are associated with a control plane name
space.
4.2 Hierarchical Routing Information Dissemination 4.2 Hierarchical Routing Information Dissemination
Routing information can be exchanged between adjacent levels of the Routing information can be exchanged between RCs bounded to adjacent
routing hierarchy i.e. Level N+1 and N, where Level N represents the levels of the RA hierarchy i.e. Level N+1 and N, where Level N
RAs contained by Level N+1. The links connecting RAs MAY be viewed represents the RAs contained by Level N+1. The links connecting RAs
as external links, and the links representing connectivity within an MAY be viewed as external links (inter-RA links), and the links
RA MAY be viewed as internal links. representing connectivity within a RA MAY be viewed as internal
links (intra-RA links). The external links to a RA at one level of
the hierarchy may be internal links in the parent RA. Intra-RA links
of a child RA MAY be hidden from the parent RA's view.
The physical location of RCs at adjacent levels, their relationship The physical location of RCs for adjacent RA levels, their
and their communication protocol are outside the scope of this relationship and their communication protocol(s) are outside the
document. No assumption is made regarding how RCs communicate scope of this document. No assumption is made regarding how RCs
between levels. If routing information is exchanged between a RC, communicate between adjacent RA levels. If routing information is
its parent, and its child RCs, it SHOULD include reachability and
MAY include (upon policy decision) node and link topology.
Multiple RCs within a RA MAY transform (filter, summarize, etc.) and W.Alanqar et al. - Expires October 2004 5
then forward information to RCs at different levels. However in this exchanged between a RC, its parent, and its child RCs, it SHOULD
case the resulting information at the receiving level must be self- include reachability and MAY include (upon policy decision) node and
consistent; this MAY be achieved using a number of mechanisms. link topology. Only the RCs of the parent RA communicate, RCs of one
childÆs RA never communicate with the RCs of other child RAs. There
SHOULD not be any dependencies on the different routing protocols
used within a RA or in different RAs.
Note: there is no relationship between multi-layer and multi-level Multiple RCs bounded to the same RA MAY transform (filter,
routing. The former implies a single routing protocol instance for summarize, etc.) and then forward information to RCs at different
multiple transport switching layers whereas the latter implies a levels. However in this case the resulting information at the
hierarchical routing topology for one transport switching layer. receiving level must be self-consistent; this MAY be achieved using
a number of mechanisms.
4.2.1 Communication between Adjacent Routing Levels Note: there is no implied relationship between multi-layer transport
networks and multi-level routing. Implementations may support a
hierarchical routing topology (multi-level) with a single routing
protocol instance for multiple transport switching layers or a
hierarchical routing topology for one transport switching layer.
1. Type of Information Exchanged 1. Type of Information Exchanged
W.Alanqar et al. - Expires July 2004 5
The type of information flowing upward (i.e. Level N to Level The type of information flowing upward (i.e. Level N to Level
N+1) and the information flowing downward (i.e. Level N+1 to N+1) and the information flowing downward (i.e. Level N+1 to
Level N) are used for similar purposes, namely, the exchange of Level N) are used for similar purposes, namely, the exchange of
reachability information and summarized topology information to reachability information and summarized topology information to
allow routing across multiple RAs. The summarization of topology allow routing across multiple RAs. The summarization of topology
information may impact the accuracy of routing and MAY require information may impact the accuracy of routing and MAY require
additional path calculation. additional path calculation.
The following information exchange are expected: The following information exchange are expected:
- Level N+1 visibility to Level N reachability and topology (or - Level N+1 visibility to Level N reachability and topology (or
upward information communication) allowing RC(s) at level N+1 upward information communication) allowing RC(s) at Level N+1
to determine the reachable endpoints from Level N. to determine the reachable endpoints from Level N.
- Level N visibility to Level N+1 reachability and topology (or - Level N visibility to Level N+1 reachability and topology (or
downward information communication) allowing RC(s) in an RA at downward information communication) allowing RC(s) bounded to a
Level N to develop paths to reachable endpoints outside of the RA at Level N to develop paths to reachable endpoints outside
RA. of the RA.
2. Interactions between Upward and Downward Communication 2. Interactions between Upward and Downward Communication
When both upward and downward information exchanges contain When both upward and downward information exchanges contain
endpoint reachability information, a feedback loop could endpoint reachability information, a feedback loop could
potentially be created. Consequently, the routing protocol MUST potentially be created. Consequently, the routing protocol MUST
include a method to: include a method to:
- prevent information propagated from a Level N+1 RA into the
Level N RA to be re-introduced into the Level N+1 RA, and
- prevent information propagated from a Level N-1 RA into the
Level N RA to be re-introduced into the Level N-1 RA.
The routing protocol is required to differentiate the routing - prevent information propagated from a Level N+1 RA's RC into
information originated at a given level RA from the one derived the Level N RA's RC to be re-introduced into the Level N+1 RA's
using the routing information received from its external RAs RC, and
(regardless of the level of the corresponding RCs). This is a
necessary condition to be fulfilled by routing protocols to be
loop free.
Also, for ASON, the routing information exchange may generate - prevent information propagated from a Level N-1 RA's RC into
transient loops at the data plane if no route recording is used the Level N RA's RC to be re-introduced into the Level N-1 RA's
during signaling. So, at the data plane, it is not the routing
exchange that guarantees (transient) loop avoidance but the W.Alanqar et al. - Expires October 2004 6
signaling protocol by recording the route until the node where RC.
computation occurs (by excluding segments already traversed).
The routing protocol SHALL differentiate the routing information
originated at a given level RA from derived routing information
(received from external RAs), even when this information is
forwarded by another RC at the same level. This is a necessary
condition to be fulfilled by routing protocols to be loop free.
3. Method of Communication 3. Method of Communication
Two approaches exist for communication between Level N and N+1. Two approaches exist for communication between Level N and N+1.
- The first approach places an instance of a Level N routing - The first approach places an instance of a Level N routing
function and an instance of a Level N+1 routing function in the function and an instance of a Level N+1 routing function in the
same system. The communications interface is within a single same system. The communications interface is within a single
system and is thus not an open interface subject to system and is thus not an open interface subject to
standardization. standardization.
W.Alanqar et al. - Expires July 2004 6
- The second approach places the Level N routing function on a - The second approach places the Level N routing function on a
separate system from the Level N+1 routing function. In this separate system from the Level N+1 routing function. In this
case, a communication interface must be used between the case, a communication interface must be used between the
systems containing the routing functions for different levels. systems containing the routing functions for different levels.
This communication interface and mechanisms are outside the This communication interface and mechanisms are outside the
scope of this document. scope of this document.
4.2.2 Configuring the Routing Hierarchy 4.3 Configuration
4.3.1 Configuring the Multi-Level Hierarchy
The RC MUST support static (i.e. operator assisted) and MAY support The RC MUST support static (i.e. operator assisted) and MAY support
automated configuration of the information describing its automated configuration of the information describing its
relationship to parent and its child within the hierarchical routing relationship to parent and its child within the hierarchical
structure (including RA ID and RC ID). When applied recursively, the structure (including RA ID and RC ID). When applied recursively, the
whole hierarchy is thus configured. whole hierarchy is thus configured.
4.2.3 Configuring RC Adjacencies 4.3.2 Configuring RC Adjacencies
The RC MUST support static (i.e. operator assisted) and MAY support The RC MUST support static (i.e. operator assisted) and MAY support
automated configuration of the information describing its control automated configuration of the information describing its associated
adjacencies to other RCs within a RA. The routing protocol SHOULD PC adjacencies to other RCs bounded to the same parent RA. The
support all the types of RC adjacencies described in Section 9 of routing protocol SHOULD support all the types of RC adjacencies
[G.7715]. The latter includes congruent topology (with distributed described in Section 9 of [G.7715]. The latter includes congruent
RC) and hubbed topology (with designated RC). topology (with distributed RC) and hubbed topology (e.g. note that
the latter does not automatically imply designated RC).
4.3 Evolution 4.4 Evolution
The containment relationships of RAs MAY change, motivated by events The containment relationships of RAs MAY change, motivated by events
such as mergers, acquisitions, and divestitures. such as mergers, acquisitions, and divestitures.
The routing protocol SHOULD be capable of supporting architectural The routing protocol SHOULD be capable of supporting architectural
evolution in terms of number of hierarchical levels, as well as evolution in terms of number of hierarchical levels of RAs, as well
aggregation and segmentation of RAs. RA IDs uniqueness within an
W.Alanqar et al. - Expires October 2004 7
as aggregation and segmentation of RAs. RA IDs uniqueness within an
administrative domain MAY facilitate these operations. The routing administrative domain MAY facilitate these operations. The routing
protocol is not expected to automatically initiate and/or execute protocol is not expected to automatically initiate and/or execute
these operations. these operations. Reconfiguration of the RA hierarchy MAY not
disrupt calls in progress, though calls being set up may fail to
4.4 Multiple Links between Nodes and RAs complete, and the call setup service may be unavailable during
reconfiguration actions.
See Section 4.5.1
4.5 Routing Attributes 4.5 Routing Attributes
Routing for transport networks is performed on a per layer basis, Routing for transport networks is performed on a per layer basis,
where the routing paradigms MAY differ among layers and within a where the routing paradigms MAY differ among layers and within a
layer. Not all equipment support the same set of transport layers or layer. Not all equipment support the same set of transport layers or
the same degree of connection flexibility at any given layer. A the same degree of connection flexibility at any given layer. A
server layer trail may support various clients, involving different server layer trail may support various clients, involving different
adaptation functions. Additionally, equipment may support variable adaptation functions. Additionally, equipment may support variable
adaptation functionality, whereby a single server layer trail adaptation functionality, whereby a single server layer trail
dynamically supports different multiplexing structures. As a result, dynamically supports different multiplexing structures. As a result,
routing information MAY include layer specific, layer independent, routing information MAY include layer specific, layer independent,
and client/server adaptation information. and client/server adaptation information.
W.Alanqar et al. - Expires July 2004 7 4.5.1 Taxonomy of Routing Attributes
4.5.1 Taxonomy of Attributes
Attributes can be organized according to the following categories: Attributes can be organized according to the following categories:
- Node related or link related - Node related or link related
- Provisioned, negotiated or automatically configured - Provisioned, negotiated or automatically configured
- Inherited or layer specific (client layers can inherit some - Inherited or layer specific (client layers can inherit some
attributes from the server layer while other attributes like attributes from the server layer while other attributes like
Link Capacity are specified by layer). Link Capacity are specified by layer).
(Component) link attributes can be statically or automatically (Component) link attributes MAY be statically or automatically
configured for each transport network layer. This may lead to configured for each transport network layer. This may lead to
unnecessary repetition. Hence, the inheritance property of unnecessary repetition. Hence, the inheritance property of
attributes can also be used to optimize the configuration process. attributes MAY also be used to optimize the configuration process.
TE links are configured through grouping of component links. ASON uses the term, SNP, for the control plane representation of a
Grouping MAY be based on different link attributes (e.g., SRLG transport plane resource. The control plane representation and
information, link weight, etc). transport plane topology is NOT assumed to be congruent, the control
plane representation SHALL not be restricted by the physical
topology. The relational grouping of SNPs for routing is termed a
SNPP. The routing function understands topology in terms of SNPP
links. Grouping MAY be based on different link attributes (e.g.,
SRLG information, link weight, etc).
Two RAs may be linked by one or more TE links. Multiple TE links may Two RAs may be linked by one or more SNPP links. Multiple SNPP links
be required when component links are not equivalent for routing MAY be required when component links are not equivalent for routing
purposes with respect to the RAs they are attached to, or to the purposes with respect to the RAs they are attached to, or to the
containing RA, or when smaller groupings are required. containing RA, or when smaller groupings are required.
W.Alanqar et al. - Expires October 2004 8
4.5.2 Commonly Advertised Information 4.5.2 Commonly Advertised Information
Advertisements MAY contain the following common set of information Advertisements MAY contain the following common set of information
regardless of whether they are link or node related: regardless of whether they are link or node related:
- RA ID of which the advertisement is bounded - RA ID of which the advertisement is bounded
- RC ID of the entity generating the advertisement - RC ID of the entity generating the advertisement
- Information to uniquely identify advertisements - Information to uniquely identify advertisements
- Information to determine whether an advertisement has been updated - Information to determine whether an advertisement has been updated
- Information to indicate when an advertisement has been derived - Information to indicate when an advertisement has been derived
from a source external to the routing area from a different level RA.
4.5.3 Node Attributes 4.5.3 Node Attributes
All nodes belong to a RA, hence the RA ID can be considered an All nodes belong to a RA, hence, the RA ID can be considered an
attribute of all nodes. Given that no distinction is made between attribute of all nodes. Given that no distinction is made between
abstract nodes and those that cannot be decomposed any further, the abstract nodes and those that cannot be decomposed any further, the
same attributes MAY be used for their advertisement. same attributes MAY be used for their advertisement. In the
following tables, Capability refers to level of support required in
the realization of a link state routing protocol, whereas Usage
refers to degree of operational and implementation flexibility.
The following Node Attributes are defined: The following Node Attributes are defined:
Attribute Capability Usage Attribute Capability Usage
----------- ----------- --------- ----------- ----------- ---------
Node ID REQUIRED REQUIRED Node ID REQUIRED REQUIRED
Reachability REQUIRED OPTIONAL Reachability REQUIRED OPTIONAL
Table 1. Node Attributes Table 1. Node Attributes
W.Alanqar et al. - Expires July 2004 8
Reachability information describes the set of endpoints that are Reachability information describes the set of endpoints that are
reachable by the associated node. It MAY be advertised as a set of reachable by the associated node. It MAY be advertised as a set of
associated address prefixes or a set of associated TE link IDs, associated external (e.g. UNI) address/address prefixes or a set of
consistently assigned within an administrative domain. associated SNPP link IDs/SNPP ID prefixes, the selection of which
MUST be consistent within the applicable scope. These are control
plane identifiers, the formats of these identifiers in a protocol
realization is implementation specific and outside the scope of this
document.
Note: no distinction is made between nodes that may have further Note: no distinction is made between nodes that may have further
internal details (i.e., abstract nodes) and those that cannot be internal details (i.e., abstract nodes) and those that cannot be
decomposed any further. decomposed any further. Hence the attributes of a node are not be
considered only as single switch attributes but MAY apply to a node
at a higher level of the hierarchy that represents a sub-network.
4.5.4 Link Attributes 4.5.4 Link Attributes
The following Link Attributes are defined: The following Link Attributes are defined:
Link Attribute Capability Usage Link Attribute Capability Usage
--------------- ----------- --------- --------------- ----------- ---------
Local TE link ID REQUIRED REQUIRED Local SNPP link ID REQUIRED REQUIRED
Remote TE link ID REQUIRED REQUIRED
TE Link Characteristics Table 3 W.Alanqar et al. - Expires October 2004 9
Remote SNPP link ID REQUIRED REQUIRED
Layer Specific Characteristics see Table 3
Table 2. Link Attributes Table 2. Link Attributes
The TE link ID must be sufficient to uniquely identify the The SNPP link ID name MUST be sufficient to uniquely identify the
corresponding transport plane resource taking into account corresponding transport plane resource taking into account
separation of data and control planes. The TE link ID format is separation of data and control planes (see Section 4.5.1, the
routing protocol specific. control plane representation and transport plane topology is not
assumed to be congruent). The SNPP link ID format is routing
protocol specific.
Note: when the remote end of a TE link is located outside of the RA, Note: when the remote end of a SNPP link is located outside of the
the remote TE link ID is OPTIONAL. RA, the remote SNPP link ID is OPTIONAL.
The following TE link characteristic attributes are defined: The following link characteristic attributes are defined:
- Signal Type: This identifies the characteristic information of the - Signal Type: This identifies the characteristic information of the
layer network. layer network.
- Link Weight: The metric indicating the relative desirability of a - Link Weight: The metric indicating the relative desirability of a
particular link over another e.g. during path computation. particular link over another e.g. during path computation.
- Resource Class: This corresponds to the set of administrative - Resource Class: This corresponds to the set of administrative
groups assigned by the operator to this link. A link MAY belong to groups assigned by the operator to this link. A link MAY belong to
zero, one or more administrative groups. zero, one or more administrative groups.
- Connection Types: This allows identification of whether the local - Connection Types: This attribute identifies whether the local SNP
component link is at a border or within an LSP region (see [HIER]) represents a TCP, CP, or can be flexibly configured as a TCP.
- Link Capacity: This provides the sum of the available and - Link Capacity: This provides the sum of the available and
potential bandwidth capacity for a particular network transport potential bandwidth capacity for a particular network transport
layer. Other capacity measures MAY be further considered. layer. Other capacity measures MAY be further considered.
- Link Availability: This represents the survivability capability - Link Availability: This represents the survivability capability
such as the protection type associated with the link. such as the protection type associated with the link.
- Diversity Support: This represents diversity information such as - Diversity Support: This represents diversity information such as
W.Alanqar et al. - Expires July 2004 9
the SRLG information associated with the link. the SRLG information associated with the link.
- Local Adaptation Support: This indicates the set of client layer - Local Adaptation Support: This indicates the set of client layer
adaptations supported by the local component link associated to adaptations supported by the TCP associated with the Local SNPP.
the local TE link. This can only exist when the "Local Connection This is only applicable when the local SNP represents a TCP or can
Type" indicates crossing of an LSP Region or can be flexibly be flexibly configured as a TCP.
assigned to be at a border or within an LSP region (see [HIER]).
TE link Characteristics Capability Usage Link Characteristics Capability Usage
----------------------- ---------- --------- ----------------------- ---------- ---------
Signal Type REQUIRED OPTIONAL Signal Type REQUIRED OPTIONAL
Link Weight REQUIRED OPTIONAL Link Weight REQUIRED OPTIONAL
Resource Class REQUIRED OPTIONAL Resource Class REQUIRED OPTIONAL
Local Connection Types REQUIRED OPTIONAL Local Connection Types REQUIRED OPTIONAL
Link Capacity REQUIRED OPTIONAL Link Capacity REQUIRED OPTIONAL
W.Alanqar et al. - Expires October 2004 10
Link Availability OPTIONAL OPTIONAL Link Availability OPTIONAL OPTIONAL
Diversity Support OPTIONAL OPTIONAL Diversity Support OPTIONAL OPTIONAL
Local Adaptation support OPTIONAL OPTIONAL Local Adaptation support OPTIONAL OPTIONAL
Table 3. TE link Characteristics Table 3. Link Characteristics
Note: separate advertisements of layer specific attributes MAY be Note: separate advertisements of layer specific attributes MAY be
chosen. However this may lead to unnecessary duplication. This can chosen. However this may lead to unnecessary duplication. This can
be avoided using the inheritance property, so that attributes be avoided using the inheritance property, so that the attributes
derivable from the local adaptation information do not need to be derivable from the local adaptation information do not need to be
advertised. advertised. Thus, an optimization MAY be used when several layers
are present by indicating when an attribute is inheritable from a
5. Backward Compatibility server layer.
Any particular realization of the ASON routing requirements MUST be
backward compatible with the considered routing protocol(s).
Backward compatibility means that at any level of the routing
hierarchy, nodes, some of which support the requirements described
in this document, and some of which do not, MUST still be capable to
operate as mandated by the OSPF, IS-IS, and/or IDR IETF WG and their
corresponding GMPLS extensions (as mandated by the CCAMP IETF WG).
Additionally, nodes (that do not support these requirements and) are 5. Security Considerations
made part of a multi-level routing hierarchy from their containing
RA(s), must be capable of:
- rejecting (or ignoring) any incoming routing information that
would be addressed to them in a way that is not detrimental to the
network as a whole
- communicating (at a given level) with any other node located
at the same level and that implements these requirements
This assumes that such nodes do not communicate directly either with
lower or upper level nodes.
Note: backward compatibility with routing protocols is a protocol ASON routing protocol MUST deliver the operational security
requirement defined in the IETF context. objectives where required. These objectives do not necessarily imply
requirements on the routing protocol itself, and MAY be met by other
established means.
W.Alanqar et al. - Expires July 2004 10 6. Conclusions
6. Security Considerations The description of the ASON routing architecture and components is
provided in terms of routing functionality. This description is only
conceptual: no physical partitioning of these functions is implied.
ASON routing protocol MUST deliver the operational security In summary, the ASON routing architecture assumes:
objectives where required. - A network is subdivided into ASON RAs, which MAY support multiple
routing protocols, no one-to-one relationship SHALL be assumed
- Routing Controllers (RC) provide for the exchange of routing
information (primitives) for the RA. The RC is protocol
independent and MAY be realized by multiple, different protocol
controllers within a RA. The routing information exchanged between
RCs SHALL be subject to policy constraints imposed at reference
points (External- and Internal-NNI)
- A multi-level RA hierarchy based on containment, only the RCs of
the parent RA communicate. RCs of child RAs never communicate with
the RCs of other child RAs. There SHOULD not be any dependencies
on the different routing protocols used within a child RA and that
of its parent. The routing information exchanged within the parent
RA SHALL be independent of both the routing protocol operating
within a child RA, and any control distribution choice(s), e.g.
centralized, fully distributed.
- For a RA, the set of RCs is referred to as an ASON routing
(control) domain. The routing information exchanged between
routing domains (inter-RA, i.e. inter-domain) SHALL be independent
of both the intra-domain routing protocol(s), and the intra-domain
control distribution choice(s), e.g. centralized, fully
distributed. RCs bounded to different RA levels MAY be co-located
within the same physical element or physically distributed.
- The routing adjacency topology (i.e. the associated PC
7. Conclusions W.Alanqar et al. - Expires October 2004 11
connectivity topology) and the transport network topology SHALL
NOT be assumed to be congruent
- The routing topology SHALL support multiple links between nodes
and RAs
This section captures from the identified ASON routing requirements In summary, the following functionality is expected from GMPLS
the missing capabilities from the GMPLS routing protocols (e.g. routing to instantiate the ASON hierarchical routing architecture
OSPF, IS-IS). realization (see [G.7715] and [G.7715.1]):
- RAs SHALL be uniquely identifiable within a carrier's network,
each having a unique RA ID within the carrier's network.
- Within a RA (one level), the routing protocol SHALL support
dissemination of hierarchical routing information (including
summarized routing information for other levels) in support of an
architecture of multiple hierarchical levels of RAs; the number of
hierarchical RA levels to be supported by a routing protocol is
implementation specific.
- The routing protocol SHALL support routing information based on a
common set of information elements as defined in [G.7715] and
[G.7715.1], divided between attributes pertaining to links and
abstract nodes (each representing either a sub-network or simply a
node). [G.7715] recognizes that the manner in which the routing
information is represented and exchanged will vary with the
routing protocol used.
- The routing protocol SHALL converge such that the distributed RDBs
become synchronized after a period of time.
The GMPLS routing protocol is required to support multiple To support hierarchical routing information dissemination within an
hierarchical levels of RAs and hierarchical routing information RA, the routing protocol MUST deliver:
dissemination including summarized routing information. However, the
number of hierarchical levels to be supported is routing protocol
implementation specific. This implies that the GMPLS routing
protocol must deliver:
- processing of routing information exchanged between adjacent - processing of routing information exchanged between adjacent
levels of the routing 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
- when multiple RCs within a RA transform (filter, summarize, etc.) - when multiple RCs bound to a RA transform (filter, summarize,
and then forward information to RC(s) at different levels that the etc.) and then forward information to RC(s) at different levels
resulting information at the receiving level is self-consistent that the resulting information at the receiving level is self-
consistent
- a mechanism to prevent re-introduction of information propagated - a mechanism to prevent re-introduction of information propagated
into the Level N RA back to the external level RA from which this into the Level N RA's RC back to the adjacent level RA's RC from
information has been initially received. It is thus expected that which this information has been initially received.
advertisements will include information when they have been
derived from a source external to the RA. Note that existing
routing protocols support mechanisms to identify advertisements of
externally derived information and therefore an analysis of their
applicability has to be considered on a per-protocol basis.
In order to support operator assisted changes in the containment In order to support operator assisted changes in the containment
relationships of RAs, the GMPLS routing protocol is expected to relationships of RAs, the routing protocol SHALL support evolution
support evolution in terms of number of hierarchical levels of RAs in terms of number of hierarchical levels of RAs. Example: support
(adding and removing RAs at the top/bottom of the hierarchy), as of non-disruptive operations such as adding and removing RAs at the
well as aggregation and segmentation of RAs. These GMPLS routing top/bottom of the hierarchy, adding or removing a hierarchical level
capabilities are considered of lower priority as they are of RAs in or from the middle of the hierarchy, as well as
implementation specific and their method of support should be aggregation and segmentation of RAs. The number of hierarchical
evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition, levels to be supported is routing protocol specific, and reflects a
support of non-disruptive operations such as adding or removing a containment relationship e.g. a RA insertion involves supporting a
hierarchical level of RAs in or from the middle of the routing different routing protocol domain in a portion of the network.
hierarchy are considered as the lowest priority requirements. Note
also that the number of hierarchical levels to be supported is
implementation specific, and reflects a containment relationship
e.g. a RA insertion involves supporting a different routing protocol
domain in a portion of the network.
Note: some members of the Design Team question if the ASON
requirement for supporting architecture evolution is a requirement
on the routing protocol (protocol-specific capability) vs. a
W.Alanqar et al. - Expires July 2004 11
capability to be provided by the architecture. For example, ASON
allows for supporting multiple protocols within each RA. The
multiple protocols share a common routing information database
(RDB), and the RDB is the component, which needs to support
architecture evolution. The Design Team invites CCAMP input to
understand the protocol-specific impacts.
GMPLS routing currently covers all node attributes considered in W.Alanqar et al. - Expires October 2004 12
[G.7715.1]. Assuming that the set of TE link IDs are numbered either Reachability information (see Section 4.5.3) of the set of endpoints
from their component/TE links or from the node address that hosts reachable by a node may be advertised either as a set of UNI
these components/TE links, no additional extensions seem to be Transport Resource addresses/ address prefixes, or a set of
required in order to advertise reachable end-points within an ASON associated SNPP link IDs/SNPP link ID prefixes, assigned and
control plane. Advertisement of externally reachable prefixes is selected consistently in their applicability scope. The formats of
built in within any routing protocol independently of its usage the control plane identifiers in a protocol realization are
in/outside GMPLS. implementation specific. Use of a routing protocol within a RA
should not restrict the choice of routing protocols for use in other
RAs (child or parent).
Note: some members of the Design Team noted that reachability As ASON does not restrict the control plane architecture choice
information (as described in Section 4.5.3) may be advertised as a used, either a co-located architecture or a physically separated
set of UNI Transport Resource address prefixes (assigned and architecture may be used. A collection of links and nodes such as a
selected consistently in their applicability scope). These members sub-network or RA MUST be able to represent itself to the wider
of the Design Team raised a concern that existing methods of network as a single logical entity with only its external links
advertising reachability may need to be examined (on a per-protocol visible to the topology database.
basis) to determine if they are also applicable for UNI Transport
Resource addresses. They invite CCAMP discussion on this aspect.
From the considered list of link attributes and characteristics, the 7. Acknowledgements
Local Adaptation support information is missing as TE link
attribute. GMPLS routing does not currently consider the use of
dedicated TE link attribute(s) to describe the cross/inter-layer
relationships. All other TE link attributes and characteristics are
currently covered. The need for a "TE metric" per component link
needs to be further assessed, in the sense that it can be currently
implemented. Further consideration is here needed regarding impacts
on TE link bundling capabilities and the increase of the routing
advertisement overhead with potentially duplicated information.
Note: ASON does not restrict the architecture choices used, either a The authors would like to thank Kireeti Kompella for having
co-located architecture or a physically separated architecture may initiated the proposal of an ASON Routing Requirement Design Team.
be used. Some members of the Design Team are concerned that GMPLS's
concept of the LSR requires a 1-to-1 relationship between the
transport plane entity and the control plane entity (Router). They
invite CCAMP input on GMPLS capabilities to support multiple
architectures i.e. how routing protocols would identify the
transport node ID vs. the router or routing controller ID when
scoping Link IDs in a link advertisement.
The inheritance property of link attributes used to optimize the 8. Intellectual Property Considerations
component/TE link configuration process is built in within GMPLS.
W.Alanqar et al. - Expires July 2004 12 The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
8. Acknowledgements Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The authors would like to thank Kireeti Kompella for having The IETF invites any interested party to bring to its attention
initiated the proposal of an ASON Routing Requirement Design Team. any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
9. Intellectual Property Considerations 8.1 IPR Disclosure Acknowledgement
The IETF takes no position regarding the validity or scope of any By submitting this Internet-Draft, I certify that any applicable
intellectual property or other rights that might be claimed to patent or other IPR claims of which I am aware have been disclosed,
pertain to the implementation or use of the technology described in and any of which I become aware will be disclosed, in accordance
this document or the extent to which any license under such rights with RFC 3668.
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any W.Alanqar et al. - Expires October 2004 13
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
10. References 9. References
10.1 Normative References 9.1 Normative References
[RFC 2026] S.Bradner, "The Internet Standards Process -- [RFC 2026] S.Bradner, "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996. Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2119] S.Bradner, "Key words for use in RFCs to Indicate [RFC 2119] 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.
[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.
skipping to change at line 691 skipping to change at line 721
[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 Architecture and Requirements for Link State
Protocols," 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). November 2001 (and Revision, January 2003).
[HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with [HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with
Generalized MPLS TE," Internet draft (work in Generalized MPLS TE," Internet draft (work in
progress), draft-ietf-mpls-lsp-hierarchy, Sept'02. progress), draft-ietf-mpls-lsp-hierarchy, September 02.
W.Alanqar et al. - Expires July 2004 13
11. Author's Addresses 10. Author's Addresses
Wesam Alanqar (Sprint) Wesam Alanqar (Sprint)
EMail: wesam.alanqar@mail.sprint.com EMail: wesam.alanqar@mail.sprint.com
Deborah Brungard (AT&T) Deborah Brungard (AT&T)
Rm. D1-3C22 - 200 S. Laurel Ave. Rm. D1-3C22 - 200 S. Laurel Ave.
Middletown, NJ 07748, USA Middletown, NJ 07748, USA
Phone: +1 732 4201573 Phone: +1 732 4201573
EMail: dbrungard@att.com EMail: dbrungard@att.com
skipping to change at line 721 skipping to change at line 749
San Jose, CA 95128, USA San Jose, CA 95128, USA
Phone: +1 408 8347894 Phone: +1 408 8347894
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
EMail: dimitri.papadimitriou@alcatel.be EMail: dimitri.papadimitriou@alcatel.be
W.Alanqar et al. - Expires October 2004 14
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
W.Alanqar et al. - Expires July 2004 14 W.Alanqar et al. - Expires October 2004 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. Administrative domain: (Recommendation G.805 For the purposes of
[G7715.1] an administrative domain represents the extent of
resources which belong to a single player such as a network
operator, a service provider, or an end-user. Administrative domains
of 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 entities that are (Control) Domain: represents a collection of (control) entities that
grouped for a particular purpose. G.8080 applies this G.805 are grouped for a particular purpose. The control plane is
recommendation concept (that defines two particular forms, the subdivided into domains matching administrative domains. Within an
administrative domain and the management domain) to the control administrative domain, further subdivisions of the control plane are
plane in the form of a control domain. The entities that are grouped recursively applied. A routing control domain is an abstract entity
in a control domain are components of the control plane. 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. Link: [See Recommendation G.805] a "topological component" which
describes a fixed relationship between a "subnetwork" or "access
group" and another "subnetwork" or "access group". Links are not
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 provides
coordination between all the planes. The following management coordination between all the planes. The following management
functional areas are performed in the management plane: performance, functional areas are performed in the management plane: performance,
fault, configuration, accounting and security management fault, configuration, accounting and security management
Management domain: See Recommendation G.805. Management domain: [See Recommendation G.805] A management domain
defines a collection of managed objects which are grouped to meet
organizational requirements according to geography, technology,
policy or other structure, and for a number of functional areas such
as configuration, security, (FCAPS), for the purpose of providing
control in a consistent manner. Management domains can be disjoint,
contained or overlapping. As such the resources within an
administrative domain can be distributed into several possible
overlapping management domains. The same resource can therefore
belong to several management domains simultaneously, but a
management domain shall not cross the border of an administrative
domain.
W.Alanqar et al. - Expires October 2004 16
SNP: The SNP is a control plane abstraction that represents an
actual or potential transport plane resource. SNPs (in different
subnetwork partitions) may represent the same transport resource. A
one-to-one correspondence should not be assumed.
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. Network defined in G.805.
User Network Interface (UNI): interfaces are located between User Network Interface (UNI): interfaces are located between
protocol controllers between a user and a control domain. protocol controllers between a user and a control domain. Note:
there is no routing function associated with a UNI reference point.
W.Alanqar et al. - Expires July 2004 15 W.Alanqar et al. - Expires October 2004 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 its identifier is used within the control plane as the
representation of this partition. Per [G.8080] a RA is defined by a representation of this partition. Per [G.8080] a RA is defined by a
set of sub-networks, the TE links that interconnect them, and the set of sub-networks, the TE links that interconnect them, and the
interfaces representing the ends of the TE links exiting that RA. A interfaces representing the ends of the TE links exiting that RA. A
RA may contain smaller RAs inter-connected by TE links. The limit of RA may contain smaller RAs inter-connected by TE links. The limit of
subdivision results in a RA that contains two sub-networks and a TE subdivision results in a RA that contains two sub-networks and a TE
skipping to change at line 808 skipping to change at line 862
functions can be classified as protocol independent (Link Resource functions can be classified as protocol independent (Link Resource
Manager or LRM, Routing Controller or RC) and protocol specific Manager or LRM, Routing Controller or RC) and protocol specific
(Protocol Controller or PC). (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 RC
is protocol independent. 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 hence possibly 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 Link Resource Manager (LRM): supplies all the relevant component and
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 Protocol Controller (PC): handles protocol specific message
exchanges according to the reference point over which the exchanges according to the reference point over which the
information is exchanged (e.g. E-NNI, I-NNI), and internal exchanges information is exchanged (e.g. E-NNI, I-NNI), and internal exchanges
with the RC. The PC function is protocol dependent. with the RC. The PC function is protocol dependent.
W.Alanqar et al. - Expires July 2004 16 W.Alanqar et al. - Expires October 2004 18
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
skipping to change at line 850 skipping to change at line 906
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
W.Alanqar et al. - Expires July 2004 17 W.Alanqar et al. - Expires October 2004 19
 End of changes. 

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