draft-ietf-ccamp-gmpls-ason-routing-reqts-01.txt		draft-ietf-ccamp-gmpls-ason-routing-reqts-02.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 Dave Meyer (Cisco Systems)
	Lyndon Ong (Ciena)		Lyndon Ong (Ciena)
	Expiration Date: May 2004 Dimitri Papadimitriou (Alcatel)		Expiration Date: July 2004 Dimitri Papadimitriou (Alcatel)
	Jonathan Sadler (Tellabs)		Jonathan Sadler (Tellabs)
	Stephen Shew (Nortel)		Stephen Shew (Nortel)
	December 2003		February 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-01.txt		draft-ietf-ccamp-gmpls-ason-routing-reqts-02.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 46		skipping to change at line 46
	Abstract		Abstract
	The Generalized MPLS (GMPLS) suite of protocols has been defined to		The Generalized MPLS (GMPLS) suite of protocols has been defined to
	control different switching technologies as well as different		control different switching technologies as well as different
	applications. These include support for requesting TDM connections		applications. These include support for requesting TDM connections
	including SONET/SDH and Optical Transport Networks (OTNs).		including SONET/SDH and Optical Transport Networks (OTNs).
	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
	of an Automatically Switched Optical Network (ASON).		for an Automatically Switched Optical Network (ASON) as defined by
			ITU-T.
	W.Alanqar et al. - Expires May 2004 1		W.Alanqar et al. - Expires July 2004 1
	1. Contributors		1. Contributors
	This document is the result of the CCAMP Working Group ASON Routing		This document is the result of the CCAMP Working Group ASON Routing
	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.
	3. Introduction		3. Introduction
	The GMPLS suite of protocol provides support for controlling		The GMPLS suite of protocols provides among other capability support
	different switching technologies as well as different applications.		for controlling different switching technologies. These include
	These include support for requesting TDM connections including		support for requesting TDM connections utilizing SONET/SDH (see ANSI
	SONET/SDH (see ANSI T1.105/ITU-T G.707) as well as Optical Transport		T1.105/ITU-T G.707) as well as Optical Transport Networks (see ITU-T
	Networks (see ITU-T G.709). However, there are certain capabilities		G.709). However, there are certain capabilities that are needed to
	that are needed to support the ITU-T G.8080 control plane		support the ITU-T G.8080 control plane architecture for the
	architecture for the Automatically Switched Optical Network (ASON).		Automatically Switched Optical Network (ASON). Therefore, it is
	Therefore, it is desirable to understand the corresponding		desirable to understand the corresponding requirements for the GMPLS
	requirements for the GMPLS protocol suite. The ASON control plane		protocol suite. The ASON control plane architecture is defined in
	architecture is defined in [G.8080] and ASON routing requirements		[G.8080] and ASON routing requirements are identified in [G.7715]
	are identified in [G.7715] and refined in [G.7715.1] for link state		and refined in [G.7715.1] for link state architectures. These
	architectures. These recommendations provide functional requirements		recommendations provide functional requirements and architecture,
	and architecture, they provide a protocol neutral approach.		they provide a protocol neutral approach.
	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 functionalities		suite of protocols to support the capabilities and functionality of
	of ASON control planes. It discusses the requirements for GMPLS		ASON control planes. It discusses the requirements for GMPLS routing
	routing that MAY subsequently lead to additional backward compatible		that MAY subsequently lead to additional backward compatible
	extensions to support the capabilities specified in the above		extensions to support the capabilities specified in the above
	referenced document. A description of backward compatibility		referenced documents. A description of backward compatibility
	considerations is provided in Section 5. Nonetheless, any protocol		considerations is provided in Section 5. Nonetheless, any protocol
	(in particular, routing) design or suggested protocol extensions is		(in particular, routing) design or suggested protocol extensions is
	strictly outside the scope of this document. An ASON (Routing)		strictly outside the scope of this document. An ASON (Routing)
	terminology section is provided in Appendix 1 and Appendix 2.		terminology section is provided in Appendix 1 and Appendix 2.
	The ASON model distinguishes reference points (representing points		The ASON model distinguishes reference points (representing points
	of protocol information exchange) defined (1) between an		of information exchange) defined (1) between an administrative
	administrative domain and a user (user-network interface or UNI),		domain and a user (user-network interface or UNI), (2) between
	(2) between administrative domains or within an administrative		administrative domains or within an administrative domain between
	domain between different control domains (external network-network		different control domains (external network-network interface or E-
	interface or E-NNI) and, (3) within the same administrative domain		NNI) and, (3) within the same administrative domain between control
	between control components (or simply controllers) of the same		components (or simply controllers) of the same control domain
	control domain (internal network-network interface or I-NNI). The		(internal network-network interface or I-NNI). The ASON model allows
	ASON model allows for the protocols used within different control		for the protocols used within different control domains to be
	domains to be different; and for the protocol used between control		different; and for the protocol used between control domains to be
	domains to be different than the protocols used within control		different than the protocols used within control domains. I-NNI
	domains. I-NNI interfaces are located between protocol controllers		control interfaces are located between protocol controllers within a
	within a control domain. E-NNI interfaces are located on protocol		control domain. E-NNI control interfaces are located on protocol
	controllers between control domains.		controllers between control domains.
	W.Alanqar et al. - Expires May 2004 2		W.Alanqar et al. - Expires July 2004 2
	The term routing information refers to the abstract representation		The term routing information refers to the abstract representation
	of network routing related information such as node and link		of network routing related information such as node and link
	attributes (see Section 4.5). No routing information is passed over		attributes (see Section 4.5). No routing information is passed over
	the UNI. Routing information exchanged over the NNI is subject to		the UNI. Routing information exchanged over the NNI is subject to
	the policy constraints at individual NNIs. The routing information		the policy constraints at individual NNIs. The routing information
	exchanged over the E-NNI encapsulates the common semantics of the		exchanged over the E-NNI encapsulates the common semantics of the
	individual domain information while allowing different		individual domain information while allowing different
	representation within each domain.		representation within each domain.
	The ASON routing architecture is based on the following assumptions:		The ASON routing architecture is based on the following assumptions:
	- A carrier's network is subdivided as Routing Areas (RAs). Each RA		- A carrier's network is subdivided as Routing Areas (RAs). Each RA
	shall be uniquely identifiable within a carrier's network (i.e.		shall be uniquely identifiable within a carrier's network (i.e.
	administrative domain). Partitioning into RAs provides for routing		administrative domain). RAs partitioning provide for routing
	information abstraction, thereby enabling scalable routing.		information abstraction, thereby enabling scalable routing.
	- Routing Controllers (RC) provide for the exchange of routing		- Routing Controllers (RC) provide for the exchange of routing
	information between and within a RA. The routing information		information between and within a RA. The routing information
	exchanged between RCs is subject to policy constraints imposed at		exchanged between RCs is subject to policy constraints imposed at
	reference points (E-NNI and I-NNI).		reference points (E-NNI and I-NNI).
	- A RA MAY support different routing protocols. There SHOULD NOT be		- For a RA, the set of RCs is referred to as a routing (control)
	any dependencies on the different routing protocols used.		domain. The RC MAY support more than one routing protocol (i.e. an
	- For a RA, the cluster of RCs is referred to as a routing domain.		RC MAY support multiple Protocol Controller (PCs)). There SHOULD
	The routing information exchanged between routing domains (i.e.		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		inter-domain) is independent of both the intra-domain routing
	protocol and the intra-domain control distribution choice(s), e.g.		protocol and the intra-domain control distribution choice(s), e.g.
	centralized, fully distributed.		centralized, fully distributed.
	- The routing adjacency topology and transport network topology		- The routing adjacency topology (i.e. the associated PC
	SHALL NOT be assumed to be congruent.		connectivity topology) and the transport network topology SHALL
			NOT be assumed to be congruent.
	The following functionality is expected from GMPLS routing to		The following functionality is expected from GMPLS routing to
	instantiate ASON routing realization (see [G.7715]):		instantiate ASON routing realization (see [G.7715] and [G.7715.1]):
	- support multiple hierarchical levels of RAs		- 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		- support hierarchical routing information dissemination including
	summarized routing information		summarized routing information
	- support for multiple links between nodes and RAs (allowing for		- support for multiple links between nodes (and between RAs) and for
	link and node diversity)		link and node diversity
	- support architectural evolution in terms of the number of levels		- support architectural evolution in terms of the number of levels
	of hierarchies, aggregation and segmentation of RAs		of hierarchies, aggregation and segmentation of RAs
	- support routing information based on a common set of information		- support routing information based on a common set of information
	elements as defined in [G.7715] and [G.7715.1], divided between		elements as defined in [G.7715] and [G.7715.1], divided between
	attributes pertaining to links and abstract nodes (each		attributes pertaining to links and abstract nodes (each
	representing either a sub-network or simply a node). [G.7715]		representing either a sub-network or simply a node). [G.7715]
	recognizes that the manner in which the routing information is		recognizes that the manner in which the routing information is
	represented and exchanged will vary with the routing protocol		represented and exchanged will vary with the routing protocol
	used.		used.
	Also, the behaviour of GMPLS routing is expected to be such that:		Also, the behaviour of GMPLS routing is expected to be such that:
	- it is scalable with respect to the number of links, nodes and RAs		- it is scalable with respect to the number of links, nodes and RAs
	- in response to a routing event (e.g. topology update, reachability		- in response to a routing event (e.g. topology update, reachability
			W.Alanqar et al. - Expires July 2004 3
	update), it delivers convergence and damping against flapping		update), it delivers convergence and damping against flapping
	- it fulfils the operational security objectives where required		- it fulfils the operational security objectives where required
	W.Alanqar et al. - Expires May 2004 3
	4. ASON Requirements for GMPLS Routing		4. ASON Requirements for GMPLS Routing
	The description of the ASON routing components (see Appendix 2) is		The description of the ASON routing components (see Appendix 2) is
	provided in terms of routing functionality. This description is only		provided in terms of routing functionality. This description is only
	conceptual: no physical partitioning of these functions is implied.		conceptual: no physical partitioning of these functions is implied.
	The Routing Controller (RC) component receive routing information		The Routing Controller (RC) components receive routing information
	from their associated Link Resource Manager(s) (LRMs) regarding TE		from their associated Link Resource Manager(s) (LRMs) regarding TE
	links and store this information in the Routing Information Database		links and store this information in the Routing Information Database
	(RDB). The RDB is replicated at each RC within the same Routing Area		(RDB). The RDB is replicated at each RC within the same Routing Area
	(RA), and MAY contain information about multiple transport plane		(RA), and MAY contain information about multiple transport plane
	network layers. Whenever the state of a TE link (or component link)		network layers. Whenever the state of a TE link (or component link)
	changes, the LRM informs the corresponding RC, which in turn updates		changes, the LRM informs the corresponding RC, which in turn updates
	its associated RDB. In order to assure RDB synchronization, the RCs		its associated RDB. In order to assure RDB synchronization, the RCs
	co-operate and exchange routing information. In this context,		co-operate and exchange routing information. In this context,
	communication between RCs is realized using a particular routing		communication between RCs is realized using a particular routing
	protocol represented by the protocol controller (PC) component and		protocol represented by the protocol controller (PC) component and
	the protocol messages are conveyed over the Signaling Control		the protocol messages are conveyed over the Signaling Control
	Network (SCN). The PC MAY convey information for one or more		Network (SCN). The PC MAY convey information for one or more
	transport network layers.		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 as the function processing the TE		Note: the RC can be thought of as the function processing the TE
	database populated by the link local/remote component and TE links		database populated by the link local/remote component and TE links
	(LRM) and by the network wide TE links through the PC which		(LRM) and by the network wide TE links through the PC which
	processes the protocol specific routing exchanges. The SCN		processes the protocol specific routing exchanges. The SCN
	corresponds to the IP control plane topology enabling routing		corresponds to the IP control plane topology enabling routing
	exchanges between GMPLS controllers (i.e. the routing adjacencies).		exchanges between GMPLS controllers (i.e. the routing adjacencies).
	The next sections detail the requirements for GMPLS routing to
	support the following ASON routing functions.
	4.1 Multiple Hierarchical Levels		4.1 Multiple Hierarchical Levels
	Routing Areas (RAs) provide for routing information abstraction,		[G.8080] introduces the concept of Routing Area (RA). RAs provide
	thereby enabling scalable routing information representation.		for routing information abstraction, thereby enabling scalable
	[G.7715] describes the use of hierarchy as one possible choice for		routing information representation. Except for the single RA case,
	routing area organization. RAs MAY be hierarchically contained: a		RAs are hierarchically contained: a higher level (parent) RA
	higher level (parent) RA contains lower level (child) RAs that in		contains lower level (child) RAs that in turn MAY also contain RAs,
	turn MAY also contain RAs, etc. Thus, RAs contain RAs that		etc. Thus, RAs contain RAs that recursively define successive
	recursively define successive hierarchical routing levels. The		hierarchical routing levels.
	realization of the routing paradigm to support hierarchical routing
	levels and the number of hierarchical levels to be supported is
	protocol specific and outside the scope of this document.
	Note: an RA can be considered as representing either an Autonomous		However, the RA containment relationship describes only an
	System (AS) or a canonical IGP routing area, both are sometimes		architectural hierarchical organization of RAs. It does not restrict
	referred to as routing regions (or simply regions).		the routing protocol realization (e.g. OSPF multi-areas, path
			computation, etc.). Moreover, the realization of the routing
			paradigm to support hierarchical routing and the number of
			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		ASON routing components are identified by values that MAY be drawn
	from several identifier spaces. The use of identifiers in a routing		from several identifier spaces (see [G.7715.1]). The use of
	protocol realization is implementation specific and outside the		identifiers in a routing protocol realization is implementation
	scope of this document.		specific and outside the scope of this document.
	W.Alanqar et al. - Expires May 2004 4
	In a multi-level routing hierarchy, it is necessary to distinguish		In a multi-level routing hierarchy, it is necessary to distinguish
	among RCs within a level and RCs at different levels of the routing		among RCs within a level and RCs at different levels of the routing
	hierarchy. Before any pair of RCs establishes communication, they		hierarchy. Before any pair of RCs establishes communication, they
	must verify they belong to the same RA. An RA identifier (RA ID) is		MUST verify they belong to the same RA (see Section 4.2). A RA
	required to provide the scope within which the RCs can communicate.		identifier (RA ID) is required to provide the scope within which the
	To distinguish between RCs within the same RA, an RC identifier (RC		RCs can communicate. To distinguish between RCs within the same RA,
	ID) is required; the RC ID must be unique within its containing RA.		an RC identifier (RC ID) is required; the RC ID must be unique
			within its containing RA.
	Note: RA IDs MAY be associated with a transport plane name space		A RA represents a partition of the data plane and its identifier
	whereas RC IDs are associated with a control plane name space.		(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
			plane 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 MAY be exchanged between adjacent levels of the		Routing information can be exchanged between adjacent levels of the
	routing hierarchy i.e. Level N+1 and N, where Level N represents the		routing 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		RAs contained by Level N+1. The links connecting RAs MAY be viewed
	as external links, and the links representing connectivity within an		as external links, and the links representing connectivity within an
	RA MAY be viewed as internal links.		RA MAY be viewed as internal links.
	The physical location of RCs at adjacent levels, their relationship		The physical location of RCs at adjacent levels, their relationship
	and their communication protocol are outside the scope of this		and their communication protocol are outside the scope of this
	document. No assumption is made regarding how RCs communicate		document. No assumption is made regarding how RCs communicate
	between levels. Information exchange between an RC, its parent, and		between levels. If routing information is exchanged between a RC,
	its child RCs, SHOULD include reachability and MAY include (upon		its parent, and its child RCs, it SHOULD include reachability and
	policy decision) node and link topology.		MAY include (upon policy decision) node and link topology.
	Multiple RCs within a RA MAY transform (filter, summarize, etc.) and		Multiple RCs within a RA MAY transform (filter, summarize, etc.) and
	then forward information to RCs at different levels. However in this		then forward information to RCs at different levels. However in this
	case the resulting information at the receiving level must be self-		case the resulting information at the receiving level must be self-
	consistent; this MAY be achieved using a number of mechanisms.		consistent; this MAY be achieved using a number of mechanisms.
			Note: there is no relationship between multi-layer and multi-level
			routing. The former implies a single routing protocol instance for
			multiple transport switching layers whereas the latter implies a
			hierarchical routing topology for one transport switching layer.
	4.2.1 Communication between Adjacent Routing Levels		4.2.1 Communication between Adjacent Routing Levels
	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) in an RA at
	Level N to develop paths to reachable endpoints outside of the		Level N to develop paths to reachable endpoints outside of the
	RA.		RA.
	W.Alanqar et al. - Expires May 2004 5
	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 mechanism to prevent re-introduction of information		include a method to:
	propagated into the Level N RA back to the external level RA from		- prevent information propagated from a Level N+1 RA into the
	which this information has been initially received.		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		The routing protocol is required to differentiate the routing
	information originated at a given level RA from the one derived		information originated at a given level RA from the one derived
	using the routing information received from its external RAs		using the routing information received from its external RAs
	(regardless of the level of the corresponding RCs). This is a		(regardless of the level of the corresponding RCs). This is a
	necessary condition to be fulfilled by routing protocols to be		necessary condition to be fulfilled by routing protocols to be
	loop free.		loop free.
	Also, for ASON, the routing information exchange may generate		Also, for ASON, the routing information exchange may generate
	transient loops at the data plane if no route recording is used		transient loops at the data plane if no route recording is used
	skipping to change at line 297		skipping to change at line 317
	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.2.2 Configuring the Routing 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 routing
	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.2.3 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 control
			adjacencies to other RCs within a RA. The routing protocol SHOULD
	W.Alanqar et al. - Expires May 2004 6		support all the types of RC adjacencies described in Section 9 of
	adjacencies to other RCs within an RA. The protocol SHOULD support		[G.7715]. The latter includes congruent topology (with distributed
	all the types of adjacencies described in Section 9 of [G.7715].		RC) and hubbed topology (with designated RC).
	4.3 Evolution		4.3 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, as well as
	aggregation and segmentation of RAs. RA IDs uniqueness within an		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.
	4.4 Multiple Links between Nodes and RAs		4.4 Multiple Links between Nodes and RAs
	See Section 4.5.3		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 equipments support the same set of transport layers		layer. Not all equipment support the same set of transport layers or
	nor 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 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
	skipping to change at line 371		skipping to change at line 394
	(Component) link attributes can be statically or automatically		(Component) link attributes can 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 can also be used to optimize the configuration process.
	TE links are configured through grouping of component links.		TE links are configured through grouping of component links.
	Grouping MAY be based on different link attributes (e.g., SRLG		Grouping MAY be based on different link attributes (e.g., SRLG
	information, link weight, etc).		information, link weight, etc).
	W.Alanqar et al. - Expires May 2004 7
	Two RAs may be linked by one or more TE links. Multiple TE links may		Two RAs may be linked by one or more TE links. Multiple TE links may
	be required when component links are not equivalent for routing		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.
	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
	skipping to change at line 404		skipping to change at line 426
	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 address prefixes or a set of associated TE link IDs,
	consistently assigned within an administrative domain.		consistently assigned within an administrative domain.
	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.
	4.5.4 Link Attributes		4.5.4 Link Attributes
	skipping to change at line 425		skipping to change at line 448
	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 TE link ID REQUIRED REQUIRED
	Remote TE link ID REQUIRED REQUIRED		Remote TE link ID REQUIRED REQUIRED
	TE Link Characteristics Table 3		TE Link Characteristics Table 3
	Table 2. Link Attributes		Table 2. Link Attributes
	W.Alanqar et al. - Expires May 2004 8
	The TE link ID must be sufficient to uniquely identify the		The TE link ID 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. The TE link ID format is
	routing protocol specific.		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 TE link is located outside of the RA,
	the remote TE link ID is OPTIONAL.		the remote TE link ID is OPTIONAL.
	The following TE link characteristic attributes are defined:		The following TE link characteristic attributes are defined:
	skipping to change at line 457		skipping to change at line 479
	component link is at a border or within an LSP region (see [HIER])		component link is at a border or within an LSP region (see [HIER])
	- 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 local component link associated to
	the local TE link. This can only exist when the "Local Connection		the local TE link. This can only exist when the "Local Connection
	Type" indicates crossing of an LSP Region or can be flexibly		Type" indicates crossing of an LSP Region or can be flexibly
	assigned to be at a border or within an LSP region (see [HIER]).		assigned to be at a border or within an LSP region (see [HIER]).
	TE link Characteristics Capability Usage		TE link Characteristics Capability Usage
	----------------------- ---------- ---------		----------------------- ---------- ---------
	skipping to change at line 478		skipping to change at line 502
	Link Weight REQUIRED OPTIONAL		Link Weight REQUIRED OPTIONAL
	Resource Class REQUIRED OPTIONAL		Resource Class REQUIRED OPTIONAL
	Local Connection Types REQUIRED OPTIONAL		Local Connection Types REQUIRED OPTIONAL
	Link Capacity REQUIRED OPTIONAL		Link Capacity REQUIRED OPTIONAL
	Link Availability OPTIONAL OPTIONAL		Link Availability OPTIONAL OPTIONAL
	Diversity Support OPTIONAL OPTIONAL		Diversity Support OPTIONAL OPTIONAL
	Local Adaptation support OPTIONAL OPTIONAL		Local Adaptation support OPTIONAL OPTIONAL
	Table 3. TE link Characteristics		Table 3. TE link Characteristics
	W.Alanqar et al. - Expires May 2004 9
	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 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.
	5. Backward Compatibility		5. Backward Compatibility
	Any particular realization of the ASON routing requirements MUST be		Any particular realization of the ASON routing requirements MUST be
	backward compatible with the considered routing protocol(s).		backward compatible with the considered routing protocol(s).
	Backward compatibility means that at any level of the routing		Backward compatibility means that at any level of the routing
	hierarchy, nodes, some of which support the requirements described		hierarchy, nodes, some of which support the requirements described
	in this document, and some of which do not, must still be capable to		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		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).		corresponding GMPLS extensions (as mandated by the CCAMP IETF WG).
	Additionally, nodes (that do not support these requirements) are		Additionally, nodes (that do not support these requirements and) are
	made part of a multi-level routing hierarchy from their containing		made part of a multi-level routing hierarchy from their containing
	RA(s), must be capable of:		RA(s), must be capable of:
	- rejecting any incoming routing information that would be		- rejecting (or ignoring) any incoming routing information that
	addressed to them in a way that is not detrimental to the		would be addressed to them in a way that is not detrimental to the
	network as a whole		network as a whole
	- communicating (at a given level) with any other node located		- communicating (at a given level) with any other node located
	at the same level and that implements these requirements		at the same level and that implements these requirements
	This assumes that such nodes do not communicate directly either with		This assumes that such nodes do not communicate directly either with
	lower or upper level nodes.		lower or upper level nodes.
			Note: backward compatibility with routing protocols is a protocol
			requirement defined in the IETF context.
			W.Alanqar et al. - Expires July 2004 10
	6. Security Considerations		6. Security Considerations
	TBD.		ASON routing protocol MUST deliver the operational security
			objectives where required.
	7. Acknowledgements		7. Conclusions
			This section captures from the identified ASON routing requirements
			the missing capabilities from the GMPLS routing protocols (e.g.
			OSPF, IS-IS).
			The GMPLS routing protocol is required to support multiple
			hierarchical levels of RAs and hierarchical routing information
			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
			levels of the routing hierarchy (i.e. Level N+1 and N) including
			reachability and upon policy decision summarized topology
			information
			- when multiple RCs within a RA transform (filter, summarize, etc.)
			and then forward information to RC(s) at different levels that the
			resulting information at the receiving level is self-consistent
			- a mechanism to prevent re-introduction of information propagated
			into the Level N RA back to the external level RA from which this
			information has been initially received. It is thus expected that
			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
			relationships of RAs, the GMPLS routing protocol is expected to
			support evolution in terms of number of hierarchical levels of RAs
			(adding and removing RAs at the top/bottom of the hierarchy), as
			well as aggregation and segmentation of RAs. These GMPLS routing
			capabilities are considered of lower priority as they are
			implementation specific and their method of support should be
			evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition,
			support of non-disruptive operations such as adding or removing a
			hierarchical level of RAs in or from the middle of the routing
			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
			[G.7715.1]. Assuming that the set of TE link IDs are numbered either
			from their component/TE links or from the node address that hosts
			these components/TE links, no additional extensions seem to be
			required in order to advertise reachable end-points within an ASON
			control plane. Advertisement of externally reachable prefixes is
			built in within any routing protocol independently of its usage
			in/outside GMPLS.
			Note: some members of the Design Team noted that reachability
			information (as described in Section 4.5.3) may be advertised as a
			set of UNI Transport Resource address prefixes (assigned and
			selected consistently in their applicability scope). These members
			of the Design Team raised a concern that existing methods of
			advertising reachability may need to be examined (on a per-protocol
			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
			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
			co-located architecture or a physically separated architecture may
			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
			component/TE link configuration process is built in within GMPLS.
			W.Alanqar et al. - Expires July 2004 12
			8. Acknowledgements
	The authors would like to thank Kireeti Kompella for having		The authors would like to thank Kireeti Kompella for having
	initiated the proposal of an ASON Routing Requirement Design Team.		initiated the proposal of an ASON Routing Requirement Design Team.
	8. Intellectual Property Considerations		9. Intellectual Property Considerations
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to		intellectual property or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; neither does it represent that it		might or might not be available; neither does it represent that it
	has made any effort to identify any such rights. Information on the		has made any effort to identify any such rights. Information on the
	IETF's procedures with respect to rights in standards-track and		IETF's procedures with respect to rights in standards-track and
	standards-related documentation can be found in BCP-11. Copies of		standards-related documentation can be found in BCP-11. Copies of
	claims of rights made available for publication and any assurances		claims of rights made available for publication and any assurances
	of licenses to be made available, or the result of an attempt made		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		to obtain a general license or permission for the use of such
	proprietary rights by implementors or users of this specification		proprietary rights by implementors or users of this specification
	can be obtained from the IETF Secretariat.		can be obtained from the IETF Secretariat.
	W.Alanqar et al. - Expires May 2004 10
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights which may cover technology that may be required to practice		rights which may cover technology that may be required to practice
	this standard. Please address the information to the IETF Executive		this standard. Please address the information to the IETF Executive
	Director.		Director.
	9. References		10. References
			10.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 563		skipping to change at line 693
	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, Sept'02.
	10. Author's Addresses		W.Alanqar et al. - Expires July 2004 13
			11. Author's Addresses
	Wesam Alanqar (Sprint)		Wesam Alanqar (Sprint)
	EMail: wesam.alanqar@mail.sprint.com		EMail: wesam.alanqar@mail.sprint.com
	Deborah Brungard (AT&T)		Deborah Brungard (AT&T)
	Rm. D1-3C22 - 200 S. Laurel Ave.		Rm. D1-3C22 - 200 S. Laurel Ave.
	Middletown, NJ 07748, USA		Middletown, NJ 07748, USA
	Phone: +1 732 4201573		Phone: +1 732 4201573
	EMail: dbrungard@att.com		EMail: dbrungard@att.com
	David Meyer (Cisco Systems)		David Meyer (Cisco Systems)
	EMail: dmm@1-4-5.net		EMail: dmm@1-4-5.net
	Lyndon Ong (Ciena Corporation)		Lyndon Ong (Ciena Corporation)
	5965 Silver Creek Valley Rd,		5965 Silver Creek Valley Rd,
	San Jose, CA 95128, USA		San Jose, CA 95128, USA
	Phone: +1 408 8347894		Phone: +1 408 8347894
	EMail: lyong@ciena.com		EMail: lyong@ciena.com
	Dimitri Papadimitriou (Alcatel)		Dimitri Papadimitriou (Alcatel)
	W.Alanqar et al. - Expires May 2004 11
	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
	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 May 2004 12		W.Alanqar et al. - Expires July 2004 14
	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: See Recommendation G.805.
	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.
	skipping to change at line 646		skipping to change at line 776
	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.
	W.Alanqar et al. - Expires May 2004 13		W.Alanqar et al. - Expires July 2004 15
	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): represents functionally either an Autonomous		Routing Area (RA): a RA represents a partition of the data plane and
	System (AS) or a canonical IGP routing area, both are sometimes		its identifier is used within the control plane as the
	referred to as routing regions (or simply regions).		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
			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
			subdivision results in a RA that contains two sub-networks and a TE
			link with a single component link.
	Routing Database (RDB): repository for the local topology, network		Routing Database (RDB): repository for the local topology, network
	topology, reachability, and other routing information that is		topology, reachability, and other routing information that is
	updated as part of the routing information exchange and may		updated as part of the routing information exchange and may
	additionally contain information that is configured. The RDB may		additionally contain information that is configured. The RDB may
	contain routing information for more than one Routing Area (RA).		contain routing information for more than one Routing Area (RA).
	Routing Components: ASON routing architecture functions. These		Routing Components: ASON routing architecture functions. These
	functions can be classified as protocol independent (Link Resource		functions can be classified as protocol independent (Link Resource
	Manager or LRM, Routing Controller or RC) and protocol specific		Manager or LRM, Routing Controller or RC) and protocol specific
	(Protocol Controller or PC).		(Protocol Controller or PC).
	- Routing Controller (RC): handles (abstract) information needed for		Routing Controller (RC): handles (abstract) information needed for
	routing and the routing information exchange with peering RCs by		routing and the routing information exchange with peering RCs by
	operating on the RDB. The RC has access to a view of the RDB. The RC		operating on the RDB. The RC has access to a view of the RDB. The RC
	is protocol independent.		is protocol independent.
	Note: Since the RDB may contain routing information pertaining to		Note: Since the RDB may contain routing information pertaining to
	multiple RAs (and hence possibly multiple layer networks), the RCs		multiple RAs (and hence possibly 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 TE link information to the RC. It informs the RC about any state		and 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.
	Internal Links: links that are fully encapsulated by a routing area		W.Alanqar et al. - Expires July 2004 16
	at a given level of hierarchy. Internal links to a child RA may be
	hidden from the parent RAs view.
	External Links: links that are incident upon the routing area. Note
	that external links to a routing area at one level of the hierarchy
	may be internal links in the parent routing area.
	W.Alanqar et al. - Expires May 2004 14
	Full Copyright Statement		Full Copyright Statement
	"Copyright (C) The Internet Society (2003). All Rights Reserved.		"Copyright (C) The Internet Society (2003). All Rights Reserved.
	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
	skipping to change at line 723		skipping to change at line 850
	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 May 2004 15		W.Alanqar et al. - Expires July 2004 17
End of changes.
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/