draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt		draft-ietf-ccamp-gmpls-ason-routing-reqts-06.txt
	Network Working Group Deborah Brungard (ATT)		This Internet-Draft, draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt, was published as an Informational RFC, RFC 4258
	Internet Draft Editor		(http://www.ietf.org/rfc/rfc4258.txt), on 2005-11-22.
	Category: Informational
	Expiration Date: April 2005 October 2004
	Requirements for Generalized MPLS (GMPLS) Routing
	for Automatically Switched Optical Network (ASON)
	draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt
	Status of this Memo
	This document is an Internet-Draft and is subject to all provisions
	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
	Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract
	The Generalized Multi-Protocol Label Switching (GMPLS) suite of
	protocols has been defined to control different switching
	technologies as well as different applications. These include support
	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
	suite of protocols to support the capabilities and functionalities
	for an Automatically Switched Optical Network (ASON) as defined by
	ITU-T.
	D.Brungard et al. - Expires April 2005 1
	Table of Contents
	Status of this Memo .............................................. 1
	Abstract ......................................................... 1
	Table of Contents ................................................ 2
	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 ................................. 8
	4.4 Evolution .................................................... 8
	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 ........................................... 10
	5. Security Considerations ...................................... 11
	6. Conclusions .................................................. 12
	7. Acknowledgements ............................................. 13
	8. References ................................................... 14
	8.1 Normative References ........................................ 14
	8.2 Informative References ...................................... 14
	9. Author's Addresses ........................................... 14
	Appendix 1: ASON Terminology .................................... 16
	Appendix 2: ASON Routing Terminology ............................ 18
	Intellectual Property Statement ................................. 19
	Disclaimer of Validity .......................................... 19
	Copyright Statement ............................................. 19
	1. Contributors
	This document is the result of the CCAMP Working Group ASON Routing
	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
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	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.
	3. Introduction
	The Generalized Multi-Protocol Label Switching (GMPLS) suite of
	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
	protocol suite. The ASON control plane architecture is defined in
	[G.8080], ASON routing requirements are identified in [G.7715], and
	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
	protocol neutral functional requirements and architecture.
	This document focuses on the routing requirements for the GMPLS suite
	of protocols to support the capabilities and functionality of ASON
	control planes. This document summarizes the ASON requirements using
	ASON terminology. This document does not address GMPLS applicability
	or GMPLS capabilities. Any protocol (in particular, routing)
	applicability, design or suggested extensions is strictly outside the
	scope of this document. ASON (Routing) terminology sections are
	provided in Appendix 1 and 2.
	The ASON routing architecture is based on the following assumptions:
	- A network is subdivided based on operator decision and criteria
	(e.g. geography, administration, and/or technology), the network
	subdivisions are defined in ASON as Routing Areas (RAs).
	- The routing architecture and protocols applied after the network
	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
	hierarchical relationship of RAs based on containment, i.e. child
	RAs are always contained within a parent RA. The hierarchical
	containment relationship of RAs provides for routing information
	abstraction, thereby enabling scalable routing information
	representation. The maximum number of hierarchical RA levels to be
	supported is not specified (outside the scope).
	- 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
	D.Brungard et al. - Expires April 2005 3
	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.
	The description of the ASON routing architecture provides for a
	conceptual reference architecture, with definition of functional
	components and common information elements to enable end-to-end
	routing in the case of protocol heterogeneity and facilitate
	management of ASON networks. This description is only conceptual: no
	physical partitioning of these functions is implied.
	4. ASON Routing Architecture and Requirements
	The fundamental architectural concept is the RA and its related
	functional components (see Appendix 2 on terminology). The routing
	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
	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 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.
	In this context, communication between RCs within the same RA is
	realized using a particular routing protocol (or multiple 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.
	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
	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
	document.
	ASON Routing components are identified by identifiers that are drawn
	from different name spaces (see [G.7715.1]). These are control plane
	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 failure of a RC, or the failure of communications between RCs,
	and the subsequent recovery from the failure condition MUST NOT
	disrupt calls in progress (i.e. already established) and their
	associated connections. Calls 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)
	[G.8080] introduces the concept of Routing Area (RA) in reference to
	a network subdivision. RAs provide for routing information
	abstraction. Except for the single RA case, RAs are hierarchically
	contained: a higher level (parent) RA contains lower level (child)
	RAs that in turn MAY also contain RAs, etc. Thus, RAs contain RAs
	that recursively define successive hierarchical RA levels.
	However, the RA containment relationship describes only an
	architectural hierarchical organization of RAs. It does not restrict
	a specific routing protocol's realization (e.g. OSPF multi-areas,
	path computation, etc.). Moreover, the realization of the routing
	paradigm to support a hierarchical organization of RAs and the number
	of hierarchical RA levels to be supported is routing protocol
	specific and outside the scope of this document.
	In a multi-level hierarchy of RAs, it is necessary to distinguish
	among RCs for the different levels of the RA hierarchy. Before any
	pair of RCs establishes communication, they MUST verify they are
	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
	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
	containing RA.
	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
	data plane partition. Each RA within a carrier's network SHALL be
	uniquely identifiable. RA IDs MAY be associated with a transport
	plane name space whereas RC IDs are associated with a control plane
	name space.
	4.2 Hierarchical Routing Information Dissemination
	D.Brungard et al. - Expires April 2005 5
	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
	represents the RAs contained by Level N+1. The links connecting RAs
	may be viewed as external links (inter-RA links), and the 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 for adjacent RA levels, their
	relationship and their communication protocol(s) are outside the
	scope of this document. No assumption is made regarding how RCs
	communicate between adjacent RA levels. If routing information is
	exchanged between a RC, its parent, and its child RCs, it SHOULD
	include reachability (see Section 4.5.3) and MAY include, upon policy
	decision, node and link topology. Communication between RAs only
	takes place between RCs with a parent/child relationship. RCs of one
	RA never communicate with RCs of another RA at the same level. There
	SHOULD not be any dependencies on the different routing protocols
	used within a RA or in different RAs.
	Multiple RCs bound to the same RA MAY transform (filter, summarize,
	etc.) and then forward information to RCs at different levels.
	However, in this case, the resulting information at the receiving
	level must be self-consistent (i.e. ensure consistency between
	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
	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
	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
	Level N) are used for similar purposes, namely, the exchange of
	reachability information and summarized topology information to
	allow routing across multiple RAs. The summarization of topology
	information may impact the accuracy of routing and may require
	additional path calculation.
	The following information exchanges are expected:
	- Level N+1 visibility to Level N reachability and topology (or
	upward information communication) allowing RC(s) at Level N+1
	to determine the reachable endpoints from Level N.
	- 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
	RA at Level N to develop paths to reachable endpoints outside
	of the RA.
	2. Interactions between Upward and Downward Communication
	When both upward and downward information exchanges contain
	endpoint reachability information, a feedback loop could
	potentially be created. Consequently, the routing protocol MUST
	include a method to:
	- 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
	RA's RC, and
	- 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
	RA's RC.
	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
	Two approaches exist for communication between Level N and N+1.
	- The first approach places an instance of a Level N routing
	function and an instance of a Level N+1 routing function in the
	same system. The communications interface is within a single
	system and is thus not an open interface subject to
	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
	separate system from the Level N+1 routing function. In this
	case, a communication interface must be used between the
	systems containing the routing functions for different levels.
	This communication interface and mechanisms are outside the
	scope of this document.
	4.3 Configuration
	4.3.1 Configuring the Multi-Level Hierarchy
	The RC MUST support static (i.e. operator assisted) and MAY support
	automated configuration of the information describing its
	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
	whole hierarchy is thus configured.
	4.3.2 Configuring RC Adjacencies
	The RC MUST support static (i.e. operator assisted) and MAY support
	automated configuration of the information describing its associated
	adjacencies to other RCs within a RA. The routing protocol SHOULD
	support all the types of RC adjacencies described in Section 9 of
	[G.7715]. The latter includes congruent topology (with distributed
	RC) and hubbed topology (e.g. note that the latter does not
	automatically imply designated RC).
	4.4 Evolution
	The containment relationships of RAs may change, motivated by events
	such as mergers, acquisitions, and divestitures.
	The routing protocol SHOULD be capable of supporting architectural
	evolution in terms of number of hierarchical levels of RAs, as well
	as aggregation and segmentation of RAs. RA ID uniqueness within an
	administrative domain may facilitate these operations. The routing
	protocol is not expected to automatically initiate and/or execute
	these operations. Reconfiguration of the RA hierarchy may not disrupt
	calls in progress, though calls being set up may fail to complete,
	and the call setup service may be unavailable during reconfiguration
	actions.
	4.5 Routing Attributes
	Routing for transport networks is performed on a per layer basis,
	where the routing paradigms MAY differ among layers and within a
	layer. Not all equipment supports the same set of transport layers or
	the same degree of connection flexibility at any given layer. A
	server layer trail may support various clients, involving different
	adaptation functions. Additionally, equipment may support variable
	adaptation functionality, whereby a single server layer trail
	dynamically supports different multiplexing structures. As a result,
	routing information MAY include layer specific, layer independent,
	and client/server adaptation information.
	4.5.1 Taxonomy of Routing Attributes
	Attributes can be organized according to the following categories:
	- Node related or link related
	- Provisioned, negotiated or automatically configured
	- Inherited or layer specific (client layers can inherit some
	attributes from the server layer while other attributes like
	Link Capacity are specified by layer).
	D.Brungard et al. - Expires April 2005 8
	(Component) link attributes MAY be statically or automatically
	configured for each transport network layer. This may lead to
	unnecessary repetition. Hence, the inheritance property of attributes
	MAY also be used to optimize the configuration process.
	ASON uses the term, SubNetwork Point (SNP), for the control plane
	representation of a transport plane resource. The control plane
	representation and 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 SNP Pool (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 SNPP links. Multiple SNPP links
	may be required when component links are not equivalent for routing
	purposes with respect to the RAs they are attached to, or to the
	containing RA, or when smaller groupings are required.
	4.5.2 Commonly Advertised Information
	Advertisements MAY contain the following common set of information
	regardless of whether they are link or node related:
	- RA ID of the RA to which the advertisement is bounded
	- RC ID of the entity generating the advertisement
	- Information to uniquely identify advertisements
	- Information to determine whether an advertisement has been updated
	- Information to indicate when an advertisement has been derived
	from a different level RA.
	4.5.3 Node Attributes
	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
	abstract nodes and those that cannot be decomposed any further, the
	same attributes MAY be used for their advertisement. In the following
	tables, Capability refers to the level of support required in the
	realization of a link state routing protocol, whereas Usage refers to
	the degree of operational control that SHOULD be available to the
	operator.
	The following Node Attributes are defined:
	Attribute Capability Usage
	----------- ----------- ---------
	Node ID REQUIRED REQUIRED
	Reachability REQUIRED OPTIONAL
	Table 1. Node Attributes
	D.Brungard et al. - Expires April 2005 9
	Reachability information describes the set of endpoints that are
	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 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
	internal details (i.e., abstract nodes) and those that cannot be
	decomposed any further. Hence the attributes of a node are not
	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
	The following Link Attributes are defined:
	Link Attribute Capability Usage
	--------------- ----------- ---------
	Local SNPP link ID REQUIRED REQUIRED
	Remote SNPP link ID REQUIRED REQUIRED
	Layer Specific Characteristics see Table 3
	Table 2. Link Attributes
	The SNPP link ID MUST be sufficient to uniquely identify (within the
	Node ID scope) the corresponding transport plane resource taking into
	account separation of data and control planes (see Section 4.5.1, the
	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 SNPP link is located outside of the
	RA, the remote SNPP link ID is OPTIONAL.
	The following link characteristic attributes are defined:
	- Signal Type: This identifies the characteristic information of the
	layer network.
	- Link Weight: The metric indicating the relative desirability of a
	particular link over another e.g. during path computation.
	- Resource Class: This corresponds to the set of administrative
	groups assigned by the operator to this link. A link MAY belong to
	zero, one or more administrative groups.
	- Connection Types: This attribute identifies whether the local SNP
	represents a Termination Connection Point (CP), a Connection Point
	(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
	potential bandwidth capacity for a particular network transport
	layer. Other capacity measures MAY be further considered.
	- Link Availability: This represents the survivability capability
	such as the protection type associated with the link.
	- Diversity Support: This represents diversity information such as
	the SRLG information associated with the link.
	- Local Adaptation Support: This indicates the set of client layer
	adaptations supported by the TCP associated with the Local SNPP.
	This is only applicable when the local SNP represents a TCP or can
	be flexibly configured as a TCP.
	Link Characteristics Capability Usage
	----------------------- ---------- ---------
	Signal Type REQUIRED OPTIONAL
	Link Weight REQUIRED OPTIONAL
	Resource Class REQUIRED OPTIONAL
	Local Connection Types REQUIRED OPTIONAL
	Link Capacity REQUIRED OPTIONAL
	Link Availability OPTIONAL OPTIONAL
	Diversity Support OPTIONAL OPTIONAL
	Local Adaptation support OPTIONAL OPTIONAL
	Table 3. Link Characteristics
	Note: separate advertisements of layer specific attributes MAY be
	chosen. However, this may lead to unnecessary duplication. This can
	be avoided using the inheritance property, so that the attributes
	derivable from the local adaptation information do not need to be
	advertised. Thus, an optimization MAY be used when several layers are
	present by indicating when an attribute is inheritable from a server
	layer.
	5. Security Considerations
	ASON routing protocol MUST deliver the operational security
	objectives where required. The overall security objectives (defined
	in ITU-T Recommendation M.3016) of confidentiality, integrity,
	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
	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.
	In summary, the ASON routing architecture assumes:
	- A network is subdivided into ASON RAs, which MAY support multiple
	routing protocols, no one-to-one relationship SHALL be assumes.
	- 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).
	- In a multi-level RA hierarchy based on containment, communication
	between RCs of different RAs only happens when there is a parent/
	child relationship between the RAs. 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
	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.
	In summary, the following functionality is expected from GMPLS
	routing to instantiate the ASON hierarchical routing architecture
	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
	D.Brungard et al. - Expires April 2005 12
	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.
	To support hierarchical routing information dissemination within an
	RA, the routing protocol MUST deliver:
	- Processing of routing information exchanged between adjacent
	levels of the hierarchy (i.e. Level N+1 and N) including
	reachability and upon policy decision summarized topology
	information.
	- Self-consistent information at the receiving level resulting from
	any transformation (filter, summarize, etc.) and forwarding of
	information from one RC to RC(s) at different levels when multiple
	RCs bound to a single RA.
	- 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
	which this information has been initially received.
	In order to support operator assisted changes in the containment
	relationships of RAs, the routing protocol SHALL support evolution in
	terms of number of hierarchical levels of RAs. For example: support
	of non-disruptive operations such as adding and removing RAs at the
	top/bottom of the hierarchy, adding or removing a hierarchical level
	of RAs in or from the middle of the hierarchy, as well as aggregation
	and segmentation of RAs. The number of hierarchical levels to be
	supported is routing protocol specific, 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
	reachable by a node may be advertised either as a set of UNI
	Transport Resource addresses/ address prefixes, or a set of
	associated SNPP link IDs/SNPP link ID prefixes, assigned and selected
	consistently in their applicability scope. The formats of the control
	plane identifiers in a protocol realization are 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).
	As ASON does not restrict the control plane architecture choice used,
	either a co-located architecture or a physically separated
	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
	network as a single logical entity with only its external links
	visible to the topology database.
	7. Acknowledgements
	D.Brungard et al. - Expires April 2005 13
	The authors would like to thank Kireeti Kompella for having initiated
	the proposal of an ASON Routing Requirement Design Team and the ITU-T
	SG15/Q14 for their careful review and input.
	8. References
	8.1 Normative References
	[RFC2026] S.Bradner, "The Internet Standards Process --
	Revision 3", BCP 9, RFC 2026, October 1996.
	[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3667] S.Bradner, "IETF Rights in Contributions", BCP 78,
	RFC 3667, February 2004.
	[RFC3668] S.Bradner, Ed., "Intellectual Property Rights in IETF
	Technology", BCP 79, RFC 3668, February 2004.
	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
	Requirements for the Automatically Switched Optical
	Network (ASON)," June 2002.
	[G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing
	Architecture and Requirements for Link State Protocols,"
	November 2003.
	[G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the
	Automatically Switched Optical Network (ASON),"
	November 2001 (and Revision, January 2003).
	9. Author's Addresses
	Wesam Alanqar (Sprint)
	EMail: wesam.alanqar@mail.sprint.com
	Deborah Brungard (AT&T)
	Rm. D1-3C22 - 200 S. Laurel Ave.
	Middletown, NJ 07748, USA
	Phone: +1 732 4201573
	EMail: dbrungard@att.com
	David Meyer (Cisco Systems)
	EMail: dmm@1-4-5.net
	Lyndon Ong (Ciena Corporation)
	D.Brungard et al. - Expires April 2005 14
	5965 Silver Creek Valley Rd,
	San Jose, CA 95128, USA
	Phone: +1 408 8347894
	EMail: lyong@ciena.com
	Dimitri Papadimitriou (Alcatel)
	Francis Wellensplein 1,
	B-2018 Antwerpen, Belgium
	Phone: +32 3 2408491
	EMail: dimitri.papadimitriou@alcatel.be
	Jonathan Sadler
	1415 W. Diehl Rd
	Naperville, IL 60563
	EMail: jonathan.sadler@tellabs.com
	Stephen Shew (Nortel Networks)
	PO Box 3511 Station C
	Ottawa, Ontario, CANADA K1Y 4H7
	Phone: +1 613 7632462
	EMail: sdshew@nortelnetworks.com
	D.Brungard et al. - Expires April 2005 15
	Appendix 1: ASON Terminology
	This document makes use of the following terms:
	Administrative domain: (see 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.
	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
	functions. Through signaling, the control plane sets up and releases
	connections, and may restore a connection in case of a failure.
	(Control) Domain: represents a collection of (control) entities that
	are grouped for a particular purpose. The control plane is subdivided
	into domains matching administrative domains. Within an
	administrative domain, further subdivisions of the control plane are
	recursively applied. A routing control domain is an abstract entity
	that hides the details of the RC distribution.
	External NNI (E-NNI): interfaces are located between protocol
	controllers between control domains.
	Internal NNI (I-NNI): interfaces are located between protocol
	controllers within control domains.
	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
	Plane, the control plane and the system as a whole. It also provides
	coordination between all the planes. The following management
	functional areas are performed in the management plane: performance,
	fault, configuration, accounting and security management
	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
	D.Brungard et al. - Expires April 2005 16
	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.
	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.
	Subnetwork Point (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.
	Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together
	for the purposes of routing.
	Termination Connection Point (TCP): A TCP represents the output of a
	Trail Termination function or the input to a Trail Termination Sink
	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
	of user information, from one location to another. It can also
	provide transfer of some control and network management information.
	The Transport Plane is layered; it is equivalent to the Transport
	Network defined in G.805 Recommendation.
	User Network Interface (UNI): interfaces are located between protocol
	controllers between a user and a control domain. Note: there is no
	routing function associated with a UNI reference point.
	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
	This document makes use of the following terms:
	Routing Area (RA): a RA represents a partition of the data plane and
	its identifier is used within the control plane as the representation
	of this partition. Per [G.8080] a RA is defined by a set of sub-
	networks, the links that interconnect them, and the interfaces
	representing the ends of the links exiting that RA. A RA may contain
	smaller RAs inter-connected by links. The limit of subdivision
	results in a RA that contains two sub-networks interconnected by a
	single link.
	Routing Database (RDB): repository for the local topology, network
	topology, reachability, and other routing information that is updated
	as part of the routing information exchange and may additionally
	contain information that is configured. The RDB may contain routing
	information for more than one Routing Area (RA).
	Routing Components: ASON routing architecture functions. These
	functions can be classified as protocol independent (Link Resource
	Manager or LRM, Routing Controller or RC) and protocol specific
	(Protocol Controller or PC).
	Routing Controller (RC): handles (abstract) information needed for
	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
	is protocol independent.
	Note: Since the RDB may contain routing information pertaining to
	multiple RAs (and possibly to multiple layer networks), the RCs
	accessing the RDB may share the routing information.
	Link Resource Manager (LRM): supplies all the relevant component and
	TE link information to the RC. It informs the RC about any state
	changes of the link resources it controls.
	Protocol Controller (PC): handles protocol specific message exchanges
	according to the reference point over which the information is
	exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC.
	The PC function is protocol dependent.
	D.Brungard et al. - Expires April 2005 18
	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
	to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.
	Acknowledgment
	Funding for the RFC Editor function is currently provided by the
	Internet Society.
	D.Brungard et al. - Expires April 2005 19
End of changes. 1 change blocks.
	0 lines changed or deleted		0 lines changed or added
This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/