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/ |