draft-ietf-ccamp-gmpls-ason-routing-reqts-04.txt   draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt 
CCAMP Working Group Wesam Alanqar (Sprint) Network Working Group Deborah Brungard (ATT)
Internet Draft Deborah Brungard (ATT) Internet Draft Editor
Category: Informational David Meyer (Cisco Systems) Category: Informational
Lyndon Ong (Ciena) Expiration Date: April 2005 October 2004
Expiration Date: November 2004 Dimitri Papadimitriou (Alcatel)
Jonathan Sadler (Tellabs)
Stephen Shew (Nortel)
May 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-04.txt draft-ietf-ccamp-gmpls-ason-routing-reqts-05.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 subject to all provisions
all provisions of Section 10 of RFC-2026. of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any 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 become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other Internet-Drafts are draft documents valid for a maximum of six months
documents at any time. It is inappropriate to use Internet- Drafts and may be updated, replaced, or obsoleted by other documents at any
as reference material or to cite them other than as "work in time. It is inappropriate to use Internet-Drafts as reference
progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The Generalized MPLS (GMPLS) suite of protocols has been defined to The Generalized Multi-Protocol Label Switching (GMPLS) suite of
control different switching technologies as well as different protocols has been defined to control different switching
applications. These include support for requesting TDM connections technologies as well as different applications. These include support
including SONET/SDH and Optical Transport Networks (OTNs). for requesting Time Division Multiplexing (TDM) connections including
Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy
(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 November 2004 1 D.Brungard et al. - Expires April 2005 1
Table of Contents Table of Contents
Status of this Memo .............................................. 1 Status of this Memo .............................................. 1
Abstract ......................................................... 1 Abstract ......................................................... 1
Table of Contents ................................................ 2
1. Contributors .................................................. 2 1. Contributors .................................................. 2
2. Conventions used in this document ............................. 2 2. Conventions used in this document ............................. 2
3. Introduction .................................................. 2 3. Introduction .................................................. 2
4. ASON Routing Architecture and Requirements .................... 4 4. ASON Routing Architecture and Requirements .................... 4
4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) ..... 5 4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) ..... 5
4.2 Hierarchical Routing Information Dissemination ............... 5 4.2 Hierarchical Routing Information Dissemination ............... 5
4.3 Configuration ................................................ 7 4.3 Configuration ................................................ 7
4.3.1 Configuring the Multi-Level Hierarchy ...................... 7 4.3.1 Configuring the Multi-Level Hierarchy ...................... 7
4.3.2 Configuring RC Adjacencies ................................. 7 4.3.2 Configuring RC Adjacencies ................................. 8
4.4 Evolution .................................................... 7 4.4 Evolution .................................................... 8
4.5 Routing Attributes ........................................... 8 4.5 Routing Attributes ........................................... 8
4.5.1 Taxonomy of Routing Attributes ............................. 8 4.5.1 Taxonomy of Routing Attributes ............................. 8
4.5.2 Commonly Advertised Information ............................ 9 4.5.2 Commonly Advertised Information ............................ 9
4.5.3 Node Attributes ............................................ 9 4.5.3 Node Attributes ............................................ 9
4.5.4 Link Attributes ............................................ 9 4.5.4 Link Attributes ........................................... 10
5. Security Considerations ...................................... 11 5. Security Considerations ...................................... 11
6. Conclusions .................................................. 11 6. Conclusions .................................................. 12
7. Acknowledgements ............................................. 13 7. Acknowledgements ............................................. 13
8. Intellectual Property Considerations ......................... 13 8. References ................................................... 14
8.1 IPR Disclosure Acknowledgement .............................. 14 8.1 Normative References ........................................ 14
9. References ................................................... 14 8.2 Informative References ...................................... 14
9.1 Normative References ........................................ 14 9. Author's Addresses ........................................... 14
9.2 Informative References ...................................... 14
10. Author's Addresses .......................................... 14
Appendix 1: ASON Terminology .................................... 16 Appendix 1: ASON Terminology .................................... 16
Appendix 2: ASON Routing Terminology ............................ 18 Appendix 2: ASON Routing Terminology ............................ 18
Full Copyright Statement ........................................ 19 Intellectual Property Statement ................................. 19
Disclaimer of Validity .......................................... 19
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. The following are the design
team member authors that contributed to the present document:
Wesam Alanqar (Sprint)
Deborah Brungard (ATT)
David Meyer (Cisco Systems)
Lyndon Ong (Ciena)
Dimitri Papadimitriou (Alcatel)
Jonathan Sadler (Tellabs)
Stephen Shew (Nortel)
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
this document are to be interpreted as described in RFC 2119 document are to be interpreted as described in RFC 2119 [RFC2119].
[RFC2119].
3. Introduction D.Brungard et al. - Expires April 2005 2
While [RFC2119] describes interpretations of these key words in terms
of protocol specifications and implementations, they are used in this
document to describe design requirements for protocol extensions.
The GMPLS suite of protocols provides among other capabilities 3. Introduction
support for controlling different switching technologies. These
include support for requesting TDM connections utilizing SONET/SDH
(see ANSI T1.105/ITU-T G.707) as well as Optical Transport Networks
(OTN, see ITU-T G.709). However, there are certain capabilities that
are needed to support the ITU-T G.8080 control plane architecture
W.Alanqar et al. - Expires November 2004 2 The Generalized Multi-Protocol Label Switching (GMPLS) suite of
for Automatically Switched Optical Network (ASON). Therefore, it is protocols provides among other capabilities support for controlling
different switching technologies. These include support for
requesting TDM connections utilizing SONET/SDH (see ANSI T1.105/ITU-T
G.707, respectively) as well as Optical Transport Networks (OTN, see
ITU-T G.709). However, there are certain capabilities that are needed
to support the ITU-T G.8080 control plane architecture for
Automatically Switched Optical Network (ASON). Therefore, it is
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], ASON routing requirements are identified in [G.7715], and [G.8080], ASON routing requirements are identified in [G.7715], and
in [G.7715.1] for ASON link state protocols. These Recommendations in [G.7715.1] for ASON link state protocols. These Recommendations
apply to all G.805 layer networks (e.g. SDH and OTN), and provide apply to all G.805 layer networks (e.g. SDH and OTN), and provide
protocol neutral functional requirements and architecture. 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
suite of protocols to support the capabilities and functionality of of protocols to support the capabilities and functionality of ASON
ASON control planes. This document summarizes the ASON requirements control planes. This document summarizes the ASON requirements using
using ASON terminology. This document does not address GMPLS ASON terminology. This document does not address GMPLS applicability
applicability or GMPLS capabilities. Any protocol (in particular, or GMPLS capabilities. Any protocol (in particular, routing)
routing) applicability, design or suggested extensions is strictly applicability, design or suggested extensions is strictly outside the
outside the scope of this document. ASON (Routing) terminology scope of this document. ASON (Routing) terminology sections are
sections are provided in Appendix 1 and 2. provided in Appendix 1 and 2.
The ASON routing architecture is based on the following assumptions: The ASON routing architecture is based on the following assumptions:
- A network is subdivided based on operator decision and criteria - A network is subdivided based on operator decision and criteria
(e.g. geography, administration, and/or technology), the network (e.g. geography, administration, and/or technology), the network
subdivisions are defined in ASON as Routing Areas (RAs). subdivisions are defined in ASON as Routing Areas (RAs).
- The routing architecture and protocols applied after the network - The routing architecture and protocols applied after the network
is subdivided is an operator's choice. A multi-level hierarchy of is subdivided is an operator's choice. A multi-level hierarchy of
RAs, as defined in ITU-T [G.7715] and [G.7715.1], provides for a RAs, as defined in ITU-T [G.7715] and [G.7715.1], provides for a
hierarchical relationship of RAs based on containment, i.e. child hierarchical relationship of RAs based on containment, i.e. child
RAs are always contained within a parent RA. The hierarchical RAs are always contained within a parent RA. The hierarchical
containment relationship of RAs provides for routing information containment relationship of RAs provides for routing information
abstraction, thereby enabling scalable routing information abstraction, thereby enabling scalable routing information
representation. The maximum number of hierarchical RA levels to be representation. The maximum number of hierarchical RA levels to be
supported is NOT specified (outside the scope). supported is not specified (outside the scope).
- Within an ASON RA and for each level of the routing hierarchy, - Within an ASON RA and for each level of the routing hierarchy,
multiple routing paradigms (hierarchical, step- by-step, source- multiple routing paradigms (hierarchical, step- by-step, source-
based), centralized or distributed path computation, and multiple based), centralized or distributed path computation, and multiple
different routing protocols MAY be supported. The architecture different routing protocols MAY be supported. The architecture
does NOT assume a one-to-one correspondence of a routing protocol does not assume a one-to-one correspondence of a routing protocol
and a RA level and allows the routing protocol(s) used within and a RA level and allows the routing protocol(s) used within
different RAs (including child and parent RAs) to be different. different RAs (including child and parent RAs) to be different.
The realization of the routing paradigm(s) to support the The realization of the routing paradigm(s) to support the
hierarchical levels of RAs is NOT specified.
D.Brungard et al. - Expires April 2005 3
hierarchical levels of RAs is not specified.
- The routing adjacency topology (i.e. the associated Protocol - The routing adjacency topology (i.e. the associated Protocol
Controller (PC) connectivity) and transport topology is NOT Controller (PC) connectivity) and transport topology is NOT
assumed to be congruent. assumed to be congruent.
- The requirements support architectural evolution, e.g. a change in - The requirements support architectural evolution, e.g. a change in
the number of RA levels, as well as aggregation and segmentation the number of RA levels, as well as aggregation and segmentation
of RAs. of RAs.
The description of the ASON routing architecture provides for a The description of the ASON routing architecture provides for a
conceptual reference architecture, with definition of functional conceptual reference architecture, with definition of functional
components and common information elements to enable end-to-end components and common information elements to enable end-to-end
routing in the case of protocol heterogeneity and facilitate routing in the case of protocol heterogeneity and facilitate
management of ASON networks. This description is only conceptual: no management of ASON networks. This description is only conceptual: no
physical partitioning of these functions is implied. physical partitioning of these functions is implied.
W.Alanqar et al. - Expires November 2004 3
4. ASON Routing Architecture and Requirements 4. ASON Routing Architecture and Requirements
The fundamental architectural concept is the RA and it's related The fundamental architectural concept is the RA and its related
functional components (see Appendix 2 on terminology). The routing functional components (see Appendix 2 on terminology). The routing
services offered by a RA are provided by a Routing Performer (RP). A services offered by a RA are provided by a Routing Performer (RP). A
RP is responsible for a single RA, and it MAY be functionally RP is responsible for a single RA, and it MAY be functionally
realized using distributed Routing Controllers (RC). The RC, itself, realized using distributed Routing Controllers (RC). The RC, itself,
MAY be implemented as a cluster of distributed entities (ASON refers MAY be implemented as a cluster of distributed entities (ASON refers
to the cluster as a Routing Control Domain (RCD)). The RC components to the cluster as a Routing Control Domain (RCD)). The RC components
for a RA receive routing topology information from their associated for a RA receive routing topology information from their associated
Link Resource Manager(s) (LRMs) and store this information in the Link Resource Manager(s) (LRMs) and store this information in the
Routing Information Database (RDB). The RDB is replicated at each RC Routing Information Database (RDB). The RDB is replicated at each RC
bounded to the same RA, and MAY contain information about multiple bounded to the same RA, and MAY contain information about multiple
transport plane network layers. Whenever the routing topology transport plane network layers. Whenever the routing topology
changes, the LRM informs the corresponding RC, which in turn updates changes, the LRM informs the corresponding RC, which in turn updates
its associated RDB. In order to assure RDB synchronization, the RCs its associated RDB. In order to assure RDB synchronization, the RCs
co-operate and exchange routing information. Path computation co-operate and exchange routing information. Path computation
functions MAY exist in each RC, MAY exist on selected RCs within the functions MAY exist in each RC, MAY exist on selected RCs within the
same RA, or MAY be centralized for the RA. same RA, or MAY be centralized for the RA.
In this context, communication between RCs within the same RA is In this context, communication between RCs within the same RA is
realized using a particular routing protocol (or multiple realized using a particular routing protocol (or multiple protocols).
protocols). In ASON, the communication component is represented by In ASON, the communication component is represented by the protocol
the protocol controller (PC) component(s) and the protocol messages controller (PC) component(s) and the protocol messages are conveyed
are conveyed over the ASON control plane's Signaling Control Network over the ASON control plane's Signaling Control Network (SCN). The PC
(SCN). The PC MAY convey information for one or more transport MAY convey information for one or more transport network layers
network layers (refer to Section 4.2 Note). The RC is protocol (refer to Section 4.2 Note). The RC is protocol independent and RC
independent and RC communications MAY be realized by multiple, communications MAY be realized by multiple, different PCs within a
different PCs within a RA. RA.
The ASON routing architecture defines a multi-level routing The ASON routing architecture defines a multi-level routing hierarchy
hierarchy of RAs based on a containment model to support routing of RAs based on a containment model to support routing information
information abstraction. [G.7715.1] defines the ASON hierarchical abstraction. [G.7715.1] defines the ASON hierarchical link state
link state routing protocol requirements for communication of routing protocol requirements for communication of routing
routing information within an RA (one level) to support hierarchical information within an RA (one level) to support hierarchical routing
routing information dissemination (including summarized routing information dissemination (including summarized routing information
information for other levels). The communication between any of the for other levels). The communication between any of the other
other functional component(s) (e.g. SCN, LRM, and between RCDs (RC-
RC communication between RAs)), is outside the scope of [G.7715.1] D.Brungard et al. - Expires April 2005 4
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 protocol requirements and, thus, is also outside the scope of this
document. document.
ASON Routing components are identified by identifiers that are drawn ASON Routing components are identified by identifiers that are drawn
from different name spaces (see [G.7715.1]). These are control plane from different name spaces (see [G.7715.1]). These are control plane
identifiers for transport resources, components, and SCN addresses. identifiers for transport resources, components, and SCN addresses.
The formats of those identifiers in a routing protocol realization The formats of those identifiers in a routing protocol realization
SHALL be implementation specific and outside the scope of this SHALL be implementation specific and outside the scope of this
document. document.
The failure of a RC, or the failure of communications between RCs, The failure of a RC, or the failure of communications between RCs,
and the subsequent recovery from the failure condition MUST NOT and the subsequent recovery from the failure condition MUST NOT
disrupt calls in progress and their associated connections. Calls disrupt calls in progress (i.e. already established) and their
associated connections. Calls being set up MAY fail to complete, and
W.Alanqar et al. - Expires November 2004 4 the call setup service MAY be unavailable during recovery actions.
being set up MAY fail to complete, and the call setup service MAY be
unavailable during recovery actions.
4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) 4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs)
[G.8080] introduces the concept of Routing Area (RA) in reference to [G.8080] introduces the concept of Routing Area (RA) in reference to
a network subdivision. RAs provide for routing information a network subdivision. RAs provide for routing information
abstraction. Except for the single RA case, RAs are hierarchically abstraction. Except for the single RA case, RAs are hierarchically
contained: a higher level (parent) RA contains lower level (child) contained: a higher level (parent) RA contains lower level (child)
RAs that in turn MAY also contain RAs, etc. Thus, RAs contain RAs RAs that in turn MAY also contain RAs, etc. Thus, RAs contain RAs
that recursively define successive hierarchical RA levels. that recursively define successive hierarchical RA 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
a specific routing protocol's realization (e.g. OSPF multi-areas, a specific routing protocol's realization (e.g. OSPF multi-areas,
path computation, etc.). Moreover, the realization of the routing path computation, etc.). Moreover, the realization of the routing
paradigm to support a hierarchical organization of RAs and the paradigm to support a hierarchical organization of RAs and the number
number of hierarchical RA levels to be supported is routing protocol of hierarchical RA levels to be supported is routing protocol
specific and outside the scope of this document. specific and outside the scope of this document.
In a multi-level hierarchy of RAs, it is necessary to distinguish In a multi-level hierarchy of RAs, it is necessary to distinguish
among RCs for the different levels of the RA hierarchy. Before any among RCs for the different levels of the RA hierarchy. Before any
pair of RCs establishes communication, they MUST verify they are pair of RCs establishes communication, they MUST verify they are
bound to the same parent RA (see Section 4.2). A RA identifier (RA bound to the same parent RA (see Section 4.2). A RA identifier (RA
ID) is required to provide the scope within which the RCs can ID) is required to provide the scope within which the RCs can
communicate. To distinguish between RCs bound to the same RA, an RC communicate. To distinguish between RCs bound to the same RA, an RC
identifier (RC ID) is required; the RC ID MUST be unique within its identifier (RC ID) is required; the RC ID MUST be unique within its
containing RA. 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. Each RA within a carrier's network SHALL be data plane partition. Each RA within a carrier's network SHALL be
uniquely identifiable. RA IDs MAY be associated with a transport uniquely identifiable. RA IDs MAY be associated with a transport
plane name space whereas RC IDs are associated with a control plane plane name space whereas RC IDs are associated with a control plane
name space. name space.
4.2 Hierarchical Routing Information Dissemination 4.2 Hierarchical Routing Information Dissemination
D.Brungard et al. - Expires April 2005 5
Routing information can be exchanged between RCs bound to adjacent Routing information can be exchanged between RCs bound to adjacent
levels of the RA hierarchy i.e. Level N+1 and N, where Level N levels of the RA hierarchy i.e. Level N+1 and N, where Level N
represents the RAs contained by Level N+1. The links connecting RAs represents the RAs contained by Level N+1. The links connecting RAs
MAY be viewed as external links (inter-RA links), and the links may be viewed as external links (inter-RA links), and the links
representing connectivity within a RA MAY be viewed as internal representing connectivity within a RA may be viewed as internal links
links (intra-RA links). The external links to a RA at one level of (intra-RA links). The external links to a RA at one level of the
the hierarchy may be internal links in the parent RA. Intra-RA links hierarchy may be internal links in the parent RA. Intra-RA links of a
of a child RA MAY be hidden from the parent RA's view. child RA MAY be hidden from the parent RA's view.
The physical location of RCs for adjacent RA levels, their The physical location of RCs for adjacent RA levels, their
relationship and their communication protocol(s) are outside the relationship and their communication protocol(s) are outside the
scope of this document. No assumption is made regarding how RCs scope of this document. No assumption is made regarding how RCs
communicate between adjacent RA levels. If routing information is communicate between adjacent RA levels. If routing information is
W.Alanqar et al. - Expires November 2004 5
exchanged between a RC, its parent, and its child RCs, it SHOULD exchanged between a RC, its parent, and its child RCs, it SHOULD
include reachability and MAY include (upon policy decision) node and include reachability (see Section 4.5.3) and MAY include, upon policy
link topology. Communication between RAs only takes place between decision, node and link topology. Communication between RAs only
RCs with a parent/child relationship. RCs of one RA never takes place between RCs with a parent/child relationship. RCs of one
communicate with RCs of another RA at the same level. There SHOULD RA never communicate with RCs of another RA at the same level. There
not be any dependencies on the different routing protocols used SHOULD not be any dependencies on the different routing protocols
within a RA or in different RAs. used within a RA or in different RAs.
Multiple RCs bound to the same RA MAY transform (filter, summarize, Multiple RCs bound to the same RA MAY transform (filter, summarize,
etc.) and then forward information to RCs at different levels. etc.) and then forward information to RCs at different levels.
However in this case the resulting information at the receiving However, in this case, the resulting information at the receiving
level must be self-consistent; this MAY be achieved using a number level must be self-consistent (i.e. ensure consistency between
of mechanisms. transform operations performed on routing information at different
levels to ensure proper information processing). This MAY be achieved
using a number of mechanisms.
Note: there is no implied relationship between multi-layer transport Note: there is no implied relationship between multi-layer transport
networks and multi-level routing. Implementations may support a networks and multi-level routing. Implementations MAY support a
hierarchical routing topology (multi-level) with a single routing hierarchical routing topology (multi-level) with a single routing
protocol instance for multiple transport switching layers or a protocol instance for multiple transport switching layers or a
hierarchical routing topology for one transport switching layer. hierarchical routing topology for one transport switching layer.
1. Type of Information Exchanged 1. Type of Information Exchanged
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 exchanges are expected: The following information exchanges 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
D.Brungard et al. - Expires April 2005 6
downward information communication) allowing RC(s) bounded to a downward information communication) allowing RC(s) bounded to a
RA at Level N to develop paths to reachable endpoints outside RA at Level N to develop paths to reachable endpoints outside
of the 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's RC into - prevent information propagated from a Level N+1 RA's RC into
the Level N RA's RC from being re-introduced into the Level N+1 the Level N RA's RC from being re-introduced into the Level N+1
RA's RC, and RA's RC, and
- prevent information propagated from a Level N-1 RA's RC into - prevent information propagated from a Level N-1 RA's RC into
W.Alanqar et al. - Expires November 2004 6
the Level N RA's RC from being re-introduced into the Level N-1 the Level N RA's RC from being re-introduced into the Level N-1
RA's RC. RA's RC.
The routing protocol SHALL differentiate the routing information The routing protocol SHALL differentiate the routing information
originated at a given level RA from derived routing information originated at a given level RA from derived routing information
(received from external RAs), even when this information is (received from external RAs), even when this information is
forwarded by another RC at the same level. This is a necessary forwarded by another RC at the same level. This is a necessary
condition to be fulfilled by routing protocols to be loop free. 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. However, information re-advertisement or
leaking MUST be performed in a consistent manner to ensure
interoperability and basic routing protocol correctness (e.g.
cost/metric value).
- 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.3 Configuration 4.3 Configuration
4.3.1 Configuring the Multi-Level Hierarchy 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 its parent and its child within the hierarchical relationship to its parent and its child within the hierarchical
D.Brungard et al. - Expires April 2005 7
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.3.2 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 associated automated configuration of the information describing its associated
adjacencies to other RCs within a RA. The routing protocol SHOULD adjacencies to other RCs within a RA. The routing protocol SHOULD
support all the types of RC adjacencies described in Section 9 of support all the types of RC adjacencies described in Section 9 of
[G.7715]. The latter includes congruent topology (with distributed [G.7715]. The latter includes congruent topology (with distributed
RC) and hubbed topology (e.g. note that the latter does not RC) and hubbed topology (e.g. note that the latter does not
automatically imply designated RC). automatically imply designated RC).
4.4 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.
W.Alanqar et al. - Expires November 2004 7
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 of RAs, as well evolution in terms of number of hierarchical levels of RAs, as well
as aggregation and segmentation of RAs. RA ID uniqueness within an as aggregation and segmentation of RAs. RA ID 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. Reconfiguration of the RA hierarchy MAY not these operations. Reconfiguration of the RA hierarchy may not disrupt
disrupt calls in progress, though calls being set up may fail to calls in progress, though calls being set up may fail to complete,
complete, and the call setup service may be unavailable during and the call setup service may be unavailable during reconfiguration
reconfiguration actions. actions.
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 supports the same set of transport layers layer. Not all equipment supports the same set of transport layers or
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.
4.5.1 Taxonomy of Routing Attributes 4.5.1 Taxonomy of Routing 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).
D.Brungard et al. - Expires April 2005 8
(Component) link attributes MAY 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
attributes MAY also be used to optimize the configuration process. MAY also be used to optimize the configuration process.
ASON uses the term, SubNetwork Point (SNP), for the control plane ASON uses the term, SubNetwork Point (SNP), for the control plane
representation of a transport plane resource. The control plane representation of a transport plane resource. The control plane
representation and transport plane topology is NOT assumed to be representation and transport plane topology is NOT assumed to be
congruent, the control plane representation SHALL not be restricted congruent, the control plane representation SHALL not be restricted
by the physical topology. The relational grouping of SNPs for by the physical topology. The relational grouping of SNPs for routing
routing is termed a SNP Pool (SNPP). The routing function is termed a SNP Pool (SNPP). The routing function understands
understands topology in terms of SNPP links. Grouping MAY be based topology in terms of SNPP links. Grouping MAY be based on different
on different link attributes (e.g., SRLG information, link weight, link attributes (e.g., SRLG information, link weight, etc).
etc).
Two RAs may be linked by one or more SNPP links. Multiple SNPP links Two RAs may be linked by one or more SNPP links. Multiple SNPP links
MAY be required when component links are not equivalent for routing may be required when component links are not equivalent for routing
W.Alanqar et al. - Expires November 2004 8
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.
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 the RA to which the advertisement is bounded - RA ID of the RA to 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 different level RA. 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. In the same attributes MAY be used for their advertisement. In the following
following tables, Capability refers to the level of support required tables, Capability refers to the level of support required in the
in the realization of a link state routing protocol, whereas Usage realization of a link state routing protocol, whereas Usage refers to
refers to the degree of operational and implementation flexibility. the degree of operational control that SHOULD be available to the
operator.
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
D.Brungard et al. - Expires April 2005 9
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 external (e.g. UNI) address/address prefixes or a set of associated external (e.g. UNI) address/address prefixes or a set of
associated SNPP link IDs/SNPP ID prefixes, the selection of which associated SNPP link IDs/SNPP ID prefixes, the selection of which
MUST be consistent within the applicable scope. These are control MUST be consistent within the applicable scope. These are control
plane identifiers, the formats of these identifiers in a protocol plane identifiers, the formats of these identifiers in a protocol
realization is implementation specific and outside the scope of this realization is implementation specific and outside the scope of this
document. 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. Hence the attributes of a node are not decomposed any further. Hence the attributes of a node are not
considered only as single switch attributes but MAY apply to a node considered only as single switch attributes but MAY apply to a node
at a higher level of the hierarchy that represents a sub-network. 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:
W.Alanqar et al. - Expires November 2004 9
Link Attribute Capability Usage Link Attribute Capability Usage
--------------- ----------- --------- --------------- ----------- ---------
Local SNPP link ID REQUIRED REQUIRED Local SNPP link ID REQUIRED REQUIRED
Remote SNPP link ID REQUIRED REQUIRED Remote SNPP link ID REQUIRED REQUIRED
Layer Specific Characteristics see Table 3 Layer Specific Characteristics see Table 3
Table 2. Link Attributes Table 2. Link Attributes
The SNPP link ID MUST be sufficient to uniquely identify the The SNPP link ID MUST be sufficient to uniquely identify (within the
corresponding transport plane resource taking into account Node ID scope) the corresponding transport plane resource taking into
separation of data and control planes (see Section 4.5.1, the account separation of data and control planes (see Section 4.5.1, the
control plane representation and transport plane topology is not control plane representation and transport plane topology is not
assumed to be congruent). The SNPP link ID format is routing assumed to be congruent). The SNPP link ID format is routing protocol
protocol specific. specific.
Note: when the remote end of a SNPP link is located outside of the Note: when the remote end of a SNPP link is located outside of the
RA, the remote SNPP link ID is OPTIONAL. RA, the remote SNPP link ID is OPTIONAL.
The following 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 attribute identifies whether the local SNP - Connection Types: This attribute identifies whether the local SNP
represents a Termination Connection Point (CP), a Connection Point represents a Termination Connection Point (CP), a Connection Point
(CP), or can be flexibly configured as a TCP. (CP), or can be flexibly configured as a TCP.
D.Brungard et al. - Expires April 2005 10
- 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
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 TCP associated with the Local SNPP. adaptations supported by the TCP associated with the Local SNPP.
This is only applicable when the local SNP represents a TCP or can This is only applicable when the local SNP represents a TCP or can
be flexibly configured as a TCP. be flexibly configured as a TCP.
Link Characteristics Capability Usage Link Characteristics Capability Usage
----------------------- ---------- --------- ----------------------- ---------- ---------
Signal Type REQUIRED OPTIONAL Signal Type REQUIRED OPTIONAL
W.Alanqar et al. - Expires November 2004 10
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
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. 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 the 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. Thus, an optimization MAY be used when several layers advertised. Thus, an optimization MAY be used when several layers are
are present by indicating when an attribute is inheritable from a present by indicating when an attribute is inheritable from a server
server layer. layer.
5. Security Considerations 5. Security Considerations
ASON routing protocol MUST deliver the operational security ASON routing protocol MUST deliver the operational security
objectives where required. These objectives do not necessarily imply objectives where required. The overall security objectives (defined
requirements on the routing protocol itself, and MAY be met by other in ITU-T Recommendation M.3016) of confidentiality, integrity,
established means. accountability may take on varying level of importance. These
objectives do not necessarily imply requirements on the routing
protocol itself, and MAY be met by other established means.
Note: a threat analysis of a proposed routing protocol SHOULD address
masquerade, eavesdropping, unauthorized access, loss or corruption of
information (includes replay attacks), repudiation, forgery and
denial of service attacks.
D.Brungard et al. - Expires April 2005 11
6. Conclusions 6. Conclusions
The description of the ASON routing architecture and components is The description of the ASON routing architecture and components is
provided in terms of routing functionality. This description is only provided in terms of routing functionality. This description is only
conceptual: no physical partitioning of these functions is implied. conceptual: no physical partitioning of these functions is implied.
In summary, the ASON routing architecture assumes: In summary, the ASON routing architecture assumes:
- A network is subdivided into ASON RAs, which MAY support multiple - A network is subdivided into ASON RAs, which MAY support multiple
routing protocols, no one-to-one relationship SHALL be assumes. routing protocols, no one-to-one relationship SHALL be assumes.
skipping to change at line 586 skipping to change at line 616
child relationship between the RAs. RCs of child RAs never child relationship between the RAs. RCs of child RAs never
communicate with the RCs of other child RAs. There SHOULD not be communicate with the RCs of other child RAs. There SHOULD not be
any dependencies on the different routing protocols used within a any dependencies on the different routing protocols used within a
child RA and that of its parent. The routing information exchanged child RA and that of its parent. The routing information exchanged
within the parent RA SHALL be independent of both the routing within the parent RA SHALL be independent of both the routing
protocol operating within a child RA, and any control distribution protocol operating within a child RA, and any control distribution
choice(s), e.g. centralized, fully distributed. choice(s), e.g. centralized, fully distributed.
- For a RA, the set of RCs is referred to as an ASON routing - For a RA, the set of RCs is referred to as an ASON routing
(control) domain. The routing information exchanged between (control) domain. The routing information exchanged between
routing domains (inter-RA, i.e. inter-domain) SHALL be independent routing domains (inter-RA, i.e. inter-domain) SHALL be independent
W.Alanqar et al. - Expires November 2004 11
of both the intra-domain routing protocol(s), and the intra-domain of both the intra-domain routing protocol(s), and the intra-domain
control distribution choice(s), e.g. centralized, fully control distribution choice(s), e.g. centralized, fully
distributed. RCs bounded to different RA levels MAY be co-located distributed. RCs bounded to different RA levels MAY be co-located
within the same physical element or physically distributed. within the same physical element or physically distributed.
- The routing adjacency topology (i.e. the associated PC - The routing adjacency topology (i.e. the associated PC
connectivity topology) and the transport network topology SHALL connectivity topology) and the transport network topology SHALL
NOT be assumed to be congruent. NOT be assumed to be congruent.
- The routing topology SHALL support multiple links between nodes - The routing topology SHALL support multiple links between nodes
and RAs. and RAs.
skipping to change at line 613 skipping to change at line 641
- Within a RA (one level), the routing protocol SHALL support - Within a RA (one level), the routing protocol SHALL support
dissemination of hierarchical routing information (including dissemination of hierarchical routing information (including
summarized routing information for other levels) in support of an summarized routing information for other levels) in support of an
architecture of multiple hierarchical levels of RAs; the number of architecture of multiple hierarchical levels of RAs; the number of
hierarchical RA levels to be supported by a routing protocol is hierarchical RA levels to be supported by a routing protocol is
implementation specific. implementation specific.
- The routing protocol SHALL support routing information based on a - The routing protocol SHALL support routing information based on a
common set of information elements as defined in [G.7715] and common set of information elements as defined in [G.7715] and
[G.7715.1], divided between attributes pertaining to links and [G.7715.1], divided between attributes pertaining to links and
abstract nodes (each representing either a sub-network or simply a abstract nodes (each representing either a sub-network or simply a
D.Brungard et al. - Expires April 2005 12
node). [G.7715] recognizes that the manner in which the routing node). [G.7715] recognizes that the manner in which the routing
information is represented and exchanged will vary with the information is represented and exchanged will vary with the
routing protocol used. routing protocol used.
- The routing protocol SHALL converge such that the distributed RDBs - The routing protocol SHALL converge such that the distributed RDBs
become synchronized after a period of time. become synchronized after a period of time.
To support hierarchical routing information dissemination within an To support hierarchical routing information dissemination within an
RA, the routing protocol MUST deliver: RA, the 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
skipping to change at line 634 skipping to change at line 664
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 RC to RC(s) at different levels when multiple information from one RC to RC(s) at different levels when multiple
RCs bound to a single RA. RCs 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.
In order to support operator assisted changes in the containment In order to support operator assisted changes in the containment
relationships of RAs, the routing protocol SHALL support evolution relationships of RAs, the routing protocol SHALL support evolution in
in terms of number of hierarchical levels of RAs. For example: terms of number of hierarchical levels of RAs. For example: support
support of non-disruptive operations such as adding and removing RAs of non-disruptive operations such as adding and removing RAs at the
at the top/bottom of the hierarchy, adding or removing a top/bottom of the hierarchy, adding or removing a hierarchical level
hierarchical level of RAs in or from the middle of the hierarchy, as of RAs in or from the middle of the hierarchy, as well as aggregation
well as aggregation and segmentation of RAs. The number of and segmentation of RAs. The number of hierarchical levels to be
supported is routing protocol specific, and reflects a containment
W.Alanqar et al. - Expires November 2004 12 relationship e.g. a RA insertion involves supporting a different
hierarchical levels to be supported is routing protocol specific, routing protocol domain in a portion of the network.
and reflects a containment relationship e.g. a RA insertion involves
supporting a different routing protocol domain in a portion of the
network.
Reachability information (see Section 4.5.3) of the set of endpoints Reachability information (see Section 4.5.3) of the set of endpoints
reachable by a node may be advertised either as a set of UNI reachable by a node may be advertised either as a set of UNI
Transport Resource addresses/ address prefixes, or a set of Transport Resource addresses/ address prefixes, or a set of
associated SNPP link IDs/SNPP link ID prefixes, assigned and associated SNPP link IDs/SNPP link ID prefixes, assigned and selected
selected consistently in their applicability scope. The formats of consistently in their applicability scope. The formats of the control
the control plane identifiers in a protocol realization are plane identifiers in a protocol realization are implementation
implementation specific. Use of a routing protocol within a RA specific. Use of a routing protocol within a RA should not restrict
should not restrict the choice of routing protocols for use in other the choice of routing protocols for use in other RAs (child or
RAs (child or parent). parent).
As ASON does not restrict the control plane architecture choice As ASON does not restrict the control plane architecture choice used,
used, either a co-located architecture or a physically separated either a co-located architecture or a physically separated
architecture may be used. A collection of links and nodes such as a architecture may be used. A collection of links and nodes such as a
sub-network or RA MUST be able to represent itself to the wider sub-network or RA MUST be able to represent itself to the wider
network as a single logical entity with only its external links network as a single logical entity with only its external links
visible to the topology database. visible to the topology database.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Kireeti Kompella for having D.Brungard et al. - Expires April 2005 13
initiated the proposal of an ASON Routing Requirement Design Team The authors would like to thank Kireeti Kompella for having initiated
and the ITU-T SG15/Q14 for their careful review and input. the proposal of an ASON Routing Requirement Design Team and the ITU-T
SG15/Q14 for their careful review and input.
8. Intellectual Property Considerations
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.
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 IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
W.Alanqar et al. - Expires November 2004 13
8.1 IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with [RFC3668].
9. References 8. References
9.1 Normative References 8.1 Normative References
[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.
[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.
[RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78, [RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004. RFC 3667, February 2004.
[RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF [RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
9.2 Informative References 8.2 Informative References
For information on the availability of the following documents,
please see 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 Architecture and Requirements for Link State Protocols,"
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).
10. Author's Addresses 9. 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
David Meyer (Cisco Systems) David Meyer (Cisco Systems)
EMail: dmm@1-4-5.net EMail: dmm@1-4-5.net
Lyndon Ong (Ciena Corporation) Lyndon Ong (Ciena Corporation)
W.Alanqar et al. - Expires November 2004 14 D.Brungard et al. - Expires April 2005 14
5965 Silver Creek Valley Rd, 5965 Silver Creek Valley Rd,
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
skipping to change at line 772 skipping to change at line 770
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 November 2004 15 D.Brungard et al. - Expires April 2005 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 Administrative domain: (see Recommendation G.805) for the purposes of
of [G7715.1] an administrative domain represents the extent of [G7715.1] an administrative domain represents the extent of resources
resources which belong to a single player such as a network which belong to a single player such as a network operator, a service
operator, a service provider, or an end-user. Administrative domains provider, or an end-user. Administrative domains of different players
of different players do not overlap amongst themselves. do not overlap amongst themselves.
Adaptation function: (see Recommendation G.805) A "transport
processing function" which processes the client layer information for
transfer over a server layer trail.
Client/Server relationship: The association between layer networks
that is performed by an "adaptation" function to allow the link
connection in the client layer network to be supported by a trail in
the server layer network.
Control plane: performs the call control and connection control Control plane: performs the call control and connection control
functions. Through signaling, the control plane sets up and releases functions. Through signaling, the control plane sets up and releases
connections, and may restore a connection in case of a failure. connections, and may restore a connection in case of a failure.
(Control) Domain: represents a collection of (control) entities that (Control) Domain: represents a collection of (control) entities that
are grouped for a particular purpose. The control plane is are grouped for a particular purpose. The control plane is subdivided
subdivided into domains matching administrative domains. Within an into domains matching administrative domains. Within an
administrative domain, further subdivisions of the control plane are administrative domain, further subdivisions of the control plane are
recursively applied. A routing control domain is an abstract entity recursively applied. A routing control domain is an abstract entity
that hides the details of the RC distribution. that hides the details of the RC distribution.
External NNI (E-NNI): interfaces are located between protocol External NNI (E-NNI): interfaces are located between protocol
controllers between control domains. controllers between control domains.
Internal NNI (I-NNI): interfaces are located between protocol Internal NNI (I-NNI): interfaces are located between protocol
controllers within control domains. controllers within control domains.
skipping to change at line 817 skipping to change at line 824
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) a management domain Management domain: (see Recommendation G.805) a management domain
defines a collection of managed objects which are grouped to meet defines a collection of managed objects which are grouped to meet
organizational requirements according to geography, technology, organizational requirements according to geography, technology,
policy or other structure, and for a number of functional areas such policy or other structure, and for a number of functional areas such
as configuration, security, (FCAPS), for the purpose of providing as configuration, security, (FCAPS), for the purpose of providing
D.Brungard et al. - Expires April 2005 16
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 belong to several management domains simultaneously, but a management
management domain shall not cross the border of an administrative domain shall not cross the border of an administrative domain.
domain.
Multiplexing: (see Recommendation G.805) Multiplexing techniques are
used to combine client layer signals. The many-to-one relationship
represents the case of several link connections of client layer
networks supported by one server layer trail at the same time.
W.Alanqar et al. - Expires November 2004 16
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
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 Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together
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.
Trail: (see Recommendation G.805) A "transport entity" which consists
of an associated pair of "unidirectional trails" capable of
simultaneously transferring information in opposite directions
between their respective inputs and outputs.
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 User Network Interface (UNI): interfaces are located between protocol
protocol controllers between a user and a control domain. Note: controllers between a user and a control domain. Note: there is no
there is no routing function associated with a UNI reference point. routing function associated with a UNI reference point.
W.Alanqar et al. - Expires November 2004 17 Variable adaptation function: A single server layer trail may
dynamically support different multiplexing structures i.e. link
connections for multiple client layer networks.
D.Brungard et al. - Expires April 2005 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
representation of this partition. Per [G.8080] a RA is defined by a of this partition. Per [G.8080] a RA is defined by a set of sub-
set of sub-networks, the links that interconnect them, and the networks, the links that interconnect them, and the interfaces
interfaces representing the ends of the links exiting that RA. A RA representing the ends of the links exiting that RA. A RA may contain
may contain smaller RAs inter-connected by links. The limit of smaller RAs inter-connected by links. The limit of subdivision
subdivision results in a RA that contains two sub-networks results in a RA that contains two sub-networks interconnected by a
interconnected by a single link. single link.
Routing Database (RDB): repository for the local topology, network Routing Database (RDB): repository for the local topology, network
topology, reachability, and other routing information that is topology, reachability, and other routing information that is updated
updated as part of the routing information exchange and may as part of the routing information exchange and may additionally
additionally contain information that is configured. The RDB may contain information that is configured. The RDB may contain routing
contain routing information for more than one Routing Area (RA). information for more than one Routing Area (RA).
Routing Components: ASON routing architecture functions. These Routing Components: ASON routing architecture functions. These
functions can be classified as protocol independent (Link Resource functions can be classified as 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 possibly to multiple layer networks), the RCs multiple RAs (and possibly to multiple layer networks), the RCs
accessing the RDB may share the routing information. accessing the RDB may share the routing information.
Link Resource Manager (LRM): supplies all the relevant component and Link Resource Manager (LRM): supplies all the relevant component and
TE link information to the RC. It informs the RC about any state TE link information to the RC. It informs the RC about any state
changes of the link resources it controls. changes of the link resources it controls.
Protocol Controller (PC): handles protocol specific message Protocol Controller (PC): handles protocol specific message exchanges
exchanges according to the reference point over which the according to the reference point over which the information is
information is exchanged (e.g. E-NNI, I-NNI), and internal exchanges exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC.
with the RC. The PC function is protocol dependent. The PC function is protocol dependent.
W.Alanqar et al. - Expires November 2004 18 D.Brungard et al. - Expires April 2005 18
Full Copyright Statement Intellectual Property Statement
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.
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 IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). 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.
This document and the information contained herein are provided on Acknowledgment
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
W.Alanqar et al. - Expires November 2004 19 Funding for the RFC Editor function is currently provided by the
Internet Society.
D.Brungard et al. - Expires April 2005 19
 End of changes. 

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