--- 1/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt 2006-02-04 22:55:42.000000000 +0100 +++ 2/draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt 2006-02-04 22:55:43.000000000 +0100 @@ -1,25 +1,24 @@ - CCAMP Working Group Wesam Alanqar (Sprint) Internet Draft Deborah Brungard (ATT) -Category: Informational Dave Meyer (Cisco Systems) +Category: Informational David Meyer (Cisco Systems) Lyndon Ong (Ciena) -Expiration Date: July 2004 Dimitri Papadimitriou (Alcatel) +Expiration Date: October 2004 Dimitri Papadimitriou (Alcatel) Jonathan Sadler (Tellabs) Stephen Shew (Nortel) - February 2004 + April 2004 Requirements for Generalized MPLS (GMPLS) Routing for Automatically Switched Optical Network (ASON) - draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt + draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC-2026. 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 @@ -39,641 +38,672 @@ The Generalized MPLS (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting TDM connections including SONET/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. -W.Alanqar et al. - Expires July 2004 1 +W.Alanqar et al. - Expires September 2004 1 + +Table of Contents + + Status of this Memo .............................................. 1 + Abstract ......................................................... 1 + 1. Contributors .................................................. 2 + 2. Conventions used in this document ............................. 2 + 3. Introduction .................................................. 2 + 4. ASON Routing Architecture and Requirements .................... 4 + 4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) ..... 5 + 4.2 Hierarchical Routing Information Dissemination ............... 5 + 4.3 Configuration ................................................ 7 + 4.3.1 Configuring the Multi-Level Hierarchy ...................... 7 + 4.3.2 Configuring RC Adjacencies ................................. 7 + 4.4 Evolution .................................................... 7 + 4.5 Routing Attributes ........................................... 8 + 4.5.1 Taxonomy of Routing Attributes ............................. 8 + 4.5.2 Commonly Advertised Information ............................ 9 + 4.5.3 Node Attributes ............................................ 9 + 4.5.4 Link Attributes ............................................ 9 + 5. Security Considerations ...................................... 11 + 6. Conclusions .................................................. 11 + 7. Acknowledgements ............................................. 13 + 8. Intellectual Property Considerations ......................... 13 + 8.1 IPR Disclosure Acknowledgement .............................. 13 + 9. References ................................................... 14 + 9.1 Normative References ........................................ 14 + 10. Author's Addresses .......................................... 14 + Appendix 1: ASON Terminology .................................... 16 + Appendix 2: ASON Routing Terminology ............................ 18 + Full Copyright Statement ........................................ 19 1. Contributors This document is the result of the CCAMP Working Group ASON Routing Requirements design team joint effort. 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. + this document are to be interpreted as described in RFC 2119 + [RFC2119]. 3. Introduction - The GMPLS suite of protocols provides among other capability support - for controlling different switching technologies. These include - support for requesting TDM connections utilizing SONET/SDH (see ANSI - T1.105/ITU-T G.707) as well as Optical Transport Networks (see ITU-T - G.709). However, there are certain capabilities that are needed to - support the ITU-T G.8080 control plane architecture for the - Automatically Switched Optical Network (ASON). Therefore, it is + The 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) 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 + +W.Alanqar et al. - Expires October 2004 2 desirable to understand the corresponding requirements for the GMPLS protocol suite. The ASON control plane architecture is defined in - [G.8080] and ASON routing requirements are identified in [G.7715] - and refined in [G.7715.1] for link state architectures. These - recommendations provide functional requirements and architecture, - they provide a protocol neutral approach. + [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. It discusses the requirements for GMPLS routing - that MAY subsequently lead to additional backward compatible - extensions to support the capabilities specified in the above - referenced documents. A description of backward compatibility - considerations is provided in Section 5. Nonetheless, any protocol - (in particular, routing) design or suggested protocol extensions is - strictly outside the scope of this document. An ASON (Routing) - terminology section is provided in Appendix 1 and Appendix 2. + 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 model distinguishes reference points (representing points - of information exchange) defined (1) between an administrative - domain and a user (user-network interface or UNI), (2) between - administrative domains or within an administrative domain between - different control domains (external network-network interface or E- - NNI) and, (3) within the same administrative domain between control - components (or simply controllers) of the same control domain - (internal network-network interface or I-NNI). The ASON model allows - for the protocols used within different control domains to be - different; and for the protocol used between control domains to be - different than the protocols used within control domains. I-NNI - control interfaces are located between protocol controllers within a - control domain. E-NNI control interfaces are located on protocol - controllers between control domains. + 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 + hierarchical levels of RAs is NOT specified. + - The routing adjacency topology (i.e. the associated Protocol + Controller (PC) connectivity) and transport topology is NOT + assumed to be congruent. + - The requirements support architectural evolution, e.g. a change in + the number of RA levels, as well as aggregation and segmentation + of RAs. -W.Alanqar et al. - Expires July 2004 2 - The term routing information refers to the abstract representation - of network routing related information such as node and link - attributes (see Section 4.5). No routing information is passed over - the UNI. Routing information exchanged over the NNI is subject to - the policy constraints at individual NNIs. The routing information - exchanged over the E-NNI encapsulates the common semantics of the - individual domain information while allowing different - representation within each domain. + 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. - The ASON routing architecture is based on the following assumptions: - - A carrier's network is subdivided as Routing Areas (RAs). Each RA - shall be uniquely identifiable within a carrier's network (i.e. - administrative domain). RAs partitioning provide for routing - information abstraction, thereby enabling scalable routing. - - Routing Controllers (RC) provide for the exchange of routing - information between and within a RA. The routing information - exchanged between RCs is subject to policy constraints imposed at - reference points (E-NNI and I-NNI). - - For a RA, the set of RCs is referred to as a routing (control) - domain. The RC MAY support more than one routing protocol (i.e. an - RC MAY support multiple Protocol Controller (PCs)). There SHOULD - NOT be any dependencies on the different routing protocols used. - - The routing information exchanged between routing domains (i.e. - inter-domain) is independent of both the intra-domain routing - protocol and the intra-domain control distribution choice(s), e.g. - centralized, fully distributed. - - The routing adjacency topology (i.e. the associated PC - connectivity topology) and the transport network topology SHALL - NOT be assumed to be congruent. +W.Alanqar et al. - Expires October 2004 3 - The following functionality is expected from GMPLS routing to - instantiate ASON routing realization (see [G.7715] and [G.7715.1]): - - support multiple hierarchical levels of RAs; the number of - hierarchical levels to be supported is routing protocol - implementation specific. - - support hierarchical routing information dissemination including - summarized routing information - - support for multiple links between nodes (and between RAs) and for - link and node diversity - - support architectural evolution in terms of the number of levels - of hierarchies, aggregation and segmentation of RAs - - support routing information based on a common set of information - elements as defined in [G.7715] and [G.7715.1], divided between - attributes pertaining to links and abstract nodes (each - representing either a sub-network or simply a node). [G.7715] - recognizes that the manner in which the routing information is - represented and exchanged will vary with the routing protocol - used. +4. ASON Routing Architecture and Requirements - 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 - - in response to a routing event (e.g. topology update, reachability + The fundamental architectural concept is the RA and it's related + functional components (see Appendix 2 on terminology). The routing + services offered by a RA are provided by a Routing Performer (RP). + An RP is responsible for a single RA, and it MAY be functionally + realized using distributed Routing Controllers (RC). The RC, itself, + MAY be implemented as a cluster of distributed entities (ASON refers + to the cluster as a Routing Control Domain (RCD)). The RC components + for a RA receive routing topology information from their associated + Link Resource Manager(s) (LRMs) and store this information in the + Routing Information Database (RDB). The RDB is replicated at each RC + bounded to the same Routing Area (RA), and MAY contain information + about multiple transport plane network layers. Whenever the routing + topology changes, the LRM informs the corresponding RC, which in + turn updates its associated RDB. In order to assure RDB + synchronization, the RCs co-operate and exchange routing + information. Path computation functions MAY exist in each RC, MAY + exist on selected RCs within the same RA, or MAY be centralized for + the RA. -W.Alanqar et al. - Expires July 2004 3 - update), it delivers convergence and damping against flapping - - it fulfils the operational security objectives where required + 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. -4. ASON Requirements for GMPLS Routing + The ASON routing architecture defines a multi-level routing + hierarchy of RAs based on a containment model to support routing + information abstraction. [G.7715.1] defines the ASON hierarchical + link state routing protocol requirements for communication of + routing information within an RA (one level) to support hierarchical + routing information dissemination (including summarized routing + information for other levels). The Communication between any of the + other functional component(s) (e.g. SCN, LRM, and between RCDs (RC- + RC communication between RAs)), is outside the scope of [G.7715.1] + protocol requirements and, thus, is also outside the scope of this + document. - The description of the ASON routing components (see Appendix 2) is - provided in terms of routing functionality. This description is only - conceptual: no physical partitioning of these functions is implied. + 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 Routing Controller (RC) components receive routing information - from their associated Link Resource Manager(s) (LRMs) regarding TE - links and store this information in the Routing Information Database - (RDB). The RDB is replicated at each RC within the same Routing Area - (RA), and MAY contain information about multiple transport plane - network layers. Whenever the state of a TE link (or component link) - changes, the LRM informs the corresponding RC, which in turn updates - its associated RDB. In order to assure RDB synchronization, the RCs - co-operate and exchange routing information. In this context, - communication between RCs is realized using a particular routing - protocol represented by the protocol controller (PC) component and - the protocol messages are conveyed over the Signaling Control - Network (SCN). The PC MAY convey information for one or more - transport network layers. Moreover, as [G7715.1] states and - illustrates in its Figure 1, ASON routing protocol requirements - deals exclusively with the PC to PC communication of the (RC) - routing information; therefore any other communication between any - other functional component(s) (e.g. SC, LRM) is also outside the - scope of this document. + The failure of a RC, or the failure of communications between RCs, + and the subsequent recover from the failure condition MUST NOT - Note: the RC can be thought of as the function processing the TE - database populated by the link local/remote component and TE links - (LRM) and by the network wide TE links through the PC which - processes the protocol specific routing exchanges. The SCN - corresponds to the IP control plane topology enabling routing - exchanges between GMPLS controllers (i.e. the routing adjacencies). +W.Alanqar et al. - Expires October 2004 4 + disrupt calls in progress 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 +4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) - [G.8080] introduces the concept of Routing Area (RA). RAs provide - for routing information abstraction, thereby enabling scalable - routing information representation. 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 routing levels. + [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 - 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 - from several identifier spaces (see [G.7715.1]). The use of - identifiers in a routing protocol realization is implementation + 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 routing hierarchy, it is necessary to distinguish - among RCs within a level and RCs at different levels of the routing - hierarchy. Before any pair of RCs establishes communication, they - MUST verify they belong to the same 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 within the same RA, - an RC identifier (RC ID) is required; the RC ID must be unique - within its containing RA. + 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 + bounded 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 bounded 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. RA IDs MAY be associated with a transport - plane name space whereas RC IDs are associated with a control plane - name space. + data plane partition. Each RA SHALL be uniquely identifiable within + a carrier's network. 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 - Routing information can be exchanged between adjacent levels of 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 - as external links, and the links representing connectivity within an - RA MAY be viewed as internal links. + Routing information can be exchanged between RCs bounded 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 at adjacent levels, their relationship - and their communication protocol are outside the scope of this - document. No assumption is made regarding how RCs communicate - between levels. If routing information is exchanged between a RC, - its parent, and its child RCs, it SHOULD include reachability and - MAY include (upon policy decision) node and link topology. + 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 - Multiple RCs within a 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; this MAY be achieved using a number of mechanisms. +W.Alanqar et al. - Expires October 2004 5 + exchanged between a RC, its parent, and its child RCs, it SHOULD + include reachability and MAY include (upon policy decision) node and + link topology. Only the RCs of the parent RA communicate, RCs of one + childĘs RA never communicate with the RCs of other child RAs. There + SHOULD not be any dependencies on the different routing protocols + used within a RA or in different RAs. - Note: there is no relationship between multi-layer and multi-level - 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. + Multiple RCs bounded 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; this MAY be achieved using + a number of mechanisms. -4.2.1 Communication between Adjacent Routing Levels + Note: there is no implied relationship between multi-layer transport + networks and multi-level routing. Implementations may support a + hierarchical routing topology (multi-level) with a single routing + protocol instance for multiple transport switching layers or a + hierarchical routing topology for one transport switching layer. 1. Type of Information Exchanged -W.Alanqar et al. - Expires July 2004 5 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 exchange are expected: + - 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. - Level N visibility to Level N+1 reachability and topology (or - downward information communication) allowing RC(s) in an RA at - Level N to develop paths to reachable endpoints outside of the - RA. + 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 into the - Level N RA to be re-introduced into the Level N+1 RA, and - - prevent information propagated from a Level N-1 RA into the - Level N RA to be re-introduced into the Level N-1 RA. - The routing protocol is required to differentiate the routing - information originated at a given level RA from the one derived - using the routing information received from its external RAs - (regardless of the level of the corresponding RCs). This is a - necessary condition to be fulfilled by routing protocols to be - loop free. + - prevent information propagated from a Level N+1 RA's RC into + the Level N RA's RC to be re-introduced into the Level N+1 RA's + RC, and - Also, for ASON, the routing information exchange may generate - transient loops at the data plane if no route recording is used - during signaling. So, at the data plane, it is not the routing - exchange that guarantees (transient) loop avoidance but the - signaling protocol by recording the route until the node where - computation occurs (by excluding segments already traversed). + - prevent information propagated from a Level N-1 RA's RC into + the Level N RA's RC to be re-introduced into the Level N-1 RA's + +W.Alanqar et al. - Expires October 2004 6 + 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. -W.Alanqar et al. - Expires July 2004 6 - 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.2.2 Configuring the Routing Hierarchy +4.3 Configuration + +4.3.1 Configuring the Multi-Level Hierarchy The RC MUST support static (i.e. operator assisted) and MAY support automated configuration of the information describing its - relationship to parent and its child within the hierarchical routing + relationship to parent and its child within the hierarchical structure (including RA ID and RC ID). When applied recursively, the whole hierarchy is thus configured. -4.2.3 Configuring RC Adjacencies +4.3.2 Configuring RC Adjacencies The RC MUST support static (i.e. operator assisted) and MAY support - automated configuration of the information describing its control - 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 (with designated RC). + automated configuration of the information describing its associated + PC adjacencies to other RCs bounded to the same parent 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.3 Evolution +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, as well as - aggregation and segmentation of RAs. RA IDs uniqueness within an + evolution in terms of number of hierarchical levels of RAs, as well + +W.Alanqar et al. - Expires October 2004 7 + as aggregation and segmentation of RAs. RA IDs uniqueness within an administrative domain MAY facilitate these operations. The routing protocol is not expected to automatically initiate and/or execute - these operations. - -4.4 Multiple Links between Nodes and RAs - - See Section 4.5.1 + 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 support 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. -W.Alanqar et al. - Expires July 2004 7 - -4.5.1 Taxonomy of Attributes +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). - (Component) link attributes can be statically or automatically + (Component) link attributes MAY be statically or automatically configured for each transport network layer. This may lead to unnecessary repetition. Hence, the inheritance property of - attributes can also be used to optimize the configuration process. + attributes MAY also be used to optimize the configuration process. - TE links are configured through grouping of component links. - Grouping MAY be based on different link attributes (e.g., SRLG - information, link weight, etc). + ASON uses the term, 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 + SNPP. The routing function understands topology in terms of SNPP + links. Grouping MAY be based on different link attributes (e.g., + SRLG information, link weight, etc). - Two RAs may be linked by one or more TE links. Multiple TE links may - be required when component links are not equivalent for routing + 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. +W.Alanqar et al. - Expires October 2004 8 + 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 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 source external to the routing area + from a different level RA. 4.5.3 Node Attributes - All nodes belong to a RA, hence the RA ID can be considered an + All nodes belong to a RA, hence, the RA ID can be considered an attribute of all nodes. Given that no distinction is made between abstract nodes and those that cannot be decomposed any further, the - same attributes MAY be used for their advertisement. + same attributes MAY be used for their advertisement. In the + following tables, Capability refers to level of support required in + the realization of a link state routing protocol, whereas Usage + refers to degree of operational and implementation flexibility. The following Node Attributes are defined: Attribute Capability Usage ----------- ----------- --------- Node ID REQUIRED REQUIRED Reachability REQUIRED OPTIONAL Table 1. Node Attributes -W.Alanqar et al. - Expires July 2004 8 Reachability information describes the set of endpoints that are reachable by the associated node. It MAY be advertised as a set of - associated address prefixes or a set of associated TE link IDs, - consistently assigned within an administrative domain. + 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. + decomposed any further. Hence the attributes of a node are not be + considered only as single switch attributes but MAY apply to a node + at a higher level of the hierarchy that represents a sub-network. 4.5.4 Link Attributes The following Link Attributes are defined: Link Attribute Capability Usage --------------- ----------- --------- - Local TE link ID REQUIRED REQUIRED - Remote TE link ID REQUIRED REQUIRED - TE Link Characteristics Table 3 + Local SNPP link ID REQUIRED REQUIRED + +W.Alanqar et al. - Expires October 2004 9 + Remote SNPP link ID REQUIRED REQUIRED + Layer Specific Characteristics see Table 3 Table 2. Link Attributes - The TE link ID must be sufficient to uniquely identify the + The SNPP link ID name MUST be sufficient to uniquely identify the corresponding transport plane resource taking into account - separation of data and control planes. The TE link ID format is - routing protocol specific. + 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 TE link is located outside of the RA, - the remote TE link ID is OPTIONAL. + Note: when the remote end of a SNPP link is located outside of the + RA, the remote SNPP link ID is OPTIONAL. - The following TE link characteristic attributes are defined: + The following link characteristic attributes are defined: - Signal Type: This identifies the characteristic information of the 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 allows identification of whether the local - component link is at a border or within an LSP region (see [HIER]) + - Connection Types: This attribute identifies whether the local SNP + represents a TCP, CP, or can be flexibly configured as a TCP. - 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 - -W.Alanqar et al. - Expires July 2004 9 the SRLG information associated with the link. - Local Adaptation Support: This indicates the set of client layer - adaptations supported by the local component link associated to - the local TE link. This can only exist when the "Local Connection - Type" indicates crossing of an LSP Region or can be flexibly - assigned to be at a border or within an LSP region (see [HIER]). + 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. - TE link Characteristics Capability Usage + 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 + +W.Alanqar et al. - Expires October 2004 10 Link Availability OPTIONAL OPTIONAL Diversity Support OPTIONAL OPTIONAL Local Adaptation support OPTIONAL OPTIONAL - Table 3. TE link Characteristics + Table 3. Link Characteristics Note: separate advertisements of layer specific attributes MAY be chosen. However this may lead to unnecessary duplication. This can - be avoided using the inheritance property, so that attributes + be avoided using the inheritance property, so that the attributes derivable from the local adaptation information do not need to be - advertised. - -5. Backward Compatibility - - Any particular realization of the ASON routing requirements MUST be - backward compatible with the considered routing protocol(s). - - Backward compatibility means that at any level of the routing - hierarchy, nodes, some of which support the requirements described - in this document, and some of which do not, MUST still be capable to - operate as mandated by the OSPF, IS-IS, and/or IDR IETF WG and their - corresponding GMPLS extensions (as mandated by the CCAMP IETF WG). + advertised. Thus, an optimization MAY be used when several layers + are present by indicating when an attribute is inheritable from a + server layer. - Additionally, nodes (that do not support these requirements and) are - made part of a multi-level routing hierarchy from their containing - RA(s), must be capable of: - - rejecting (or ignoring) any incoming routing information that - would be addressed to them in a way that is not detrimental to the - network as a whole - - communicating (at a given level) with any other node located - at the same level and that implements these requirements - This assumes that such nodes do not communicate directly either with - lower or upper level nodes. +5. Security Considerations - Note: backward compatibility with routing protocols is a protocol - requirement defined in the IETF context. + ASON routing protocol MUST deliver the operational security + objectives where required. These objectives do not necessarily imply + requirements on the routing protocol itself, and MAY be met by other + established means. -W.Alanqar et al. - Expires July 2004 10 +6. Conclusions -6. Security Considerations + The description of the ASON routing architecture and components is + provided in terms of routing functionality. This description is only + conceptual: no physical partitioning of these functions is implied. - ASON routing protocol MUST deliver the operational security - objectives where required. + 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 assumed + - Routing Controllers (RC) provide for the exchange of routing + information (primitives) for the RA. The RC is protocol + independent and MAY be realized by multiple, different protocol + controllers within a RA. The routing information exchanged between + RCs SHALL be subject to policy constraints imposed at reference + points (External- and Internal-NNI) + - A multi-level RA hierarchy based on containment, only the RCs of + the parent RA communicate. RCs of child RAs never communicate with + the RCs of other child RAs. There SHOULD not be any dependencies + on the different routing protocols used within a child RA and that + of its parent. The routing information exchanged within the parent + RA SHALL be independent of both the routing protocol operating + within a child RA, and any control distribution choice(s), e.g. + centralized, fully distributed. + - For a RA, the set of RCs is referred to as an ASON routing + (control) domain. The routing information exchanged between + routing domains (inter-RA, i.e. inter-domain) SHALL be independent + of both the intra-domain routing protocol(s), and the intra-domain + control distribution choice(s), e.g. centralized, fully + distributed. RCs bounded to different RA levels MAY be co-located + within the same physical element or physically distributed. + - The routing adjacency topology (i.e. the associated PC -7. Conclusions +W.Alanqar et al. - Expires October 2004 11 + connectivity topology) and the transport network topology SHALL + NOT be assumed to be congruent + - The routing topology SHALL support multiple links between nodes + and RAs - This section captures from the identified ASON routing requirements - the missing capabilities from the GMPLS routing protocols (e.g. - OSPF, IS-IS). + 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 + node). [G.7715] recognizes that the manner in which the routing + information is represented and exchanged will vary with the + routing protocol used. + - The routing protocol SHALL converge such that the distributed RDBs + become synchronized after a period of time. - The GMPLS routing protocol is required to support multiple - 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: + To support hierarchical routing information dissemination within an + RA, the routing protocol MUST deliver: - processing of routing information exchanged between adjacent - levels of the routing hierarchy (i.e. Level N+1 and N) including + levels of the hierarchy (i.e. Level N+1 and N) including reachability and upon policy decision summarized topology 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 + - when multiple RCs bound to 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. + 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 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. + relationships of RAs, the routing protocol SHALL support evolution + in terms of number of hierarchical levels of RAs. 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. - 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. +W.Alanqar et al. - Expires October 2004 12 + 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). - 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. + 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. - 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. +7. Acknowledgements - 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 authors would like to thank Kireeti Kompella for having + initiated the proposal of an ASON Routing Requirement Design Team. - The inheritance property of link attributes used to optimize the - component/TE link configuration process is built in within GMPLS. +8. Intellectual Property Considerations -W.Alanqar et al. - Expires July 2004 12 + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed + to pertain to the implementation or use of the technology + described in this document or the extent to which any license + under such rights might or might not be available; nor does it + represent that it has made any independent effort to identify any + such rights. Information on the procedures with respect to rights + in RFC documents can be found in BCP 78 and BCP 79. -8. Acknowledgements + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use + of such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository + at http://www.ietf.org/ipr. - The authors would like to thank Kireeti Kompella for having - initiated the proposal of an ASON Routing Requirement Design Team. + 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. -9. Intellectual Property Considerations +8.1 IPR Disclosure Acknowledgement - The IETF takes no position regarding the validity or scope of any - intellectual property 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; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. Copies of - claims of rights made available for publication and any assurances - of licenses to be made available, or the result of an attempt made - to obtain a general license or permission for the use of such - proprietary rights by implementors or users of this specification - can be obtained from the IETF Secretariat. + By submitting this Internet-Draft, I certify that any applicable + patent or other IPR claims of which I am aware have been disclosed, + and any of which I become aware will be disclosed, in accordance + with RFC 3668. - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights which may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. +W.Alanqar et al. - Expires October 2004 13 -10. References +9. References -10.1 Normative References +9.1 Normative References [RFC 2026] S.Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC 2119] S.Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and Requirements for the Automatically Switched Optical Network (ASON)," June 2002. @@ -681,25 +711,23 @@ [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). [HIER] K.Kompella and Y.Rekhter, "LSP Hierarchy with Generalized MPLS TE," Internet draft (work in - progress), draft-ietf-mpls-lsp-hierarchy, Sept'02. - -W.Alanqar et al. - Expires July 2004 13 + progress), draft-ietf-mpls-lsp-hierarchy, September 02. -11. Author's Addresses +10. 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 @@ -711,78 +739,104 @@ 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 +W.Alanqar et al. - Expires October 2004 14 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 -W.Alanqar et al. - Expires July 2004 14 +W.Alanqar et al. - Expires October 2004 15 -Appendix 1 - ASON Terminology +Appendix 1: ASON Terminology This document makes use of the following terms: - Administrative domain: See Recommendation G.805. + Administrative domain: (Recommendation G.805 For the purposes of + [G7715.1] an administrative domain represents the extent of + resources which belong to a single player such as a network + operator, a service provider, or an end-user. Administrative domains + of different players do not overlap amongst themselves. Control plane: performs the call control and connection control 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 entities that are - grouped for a particular purpose. G.8080 applies this G.805 - recommendation concept (that defines two particular forms, the - administrative domain and the management domain) to the control - plane in the form of a control domain. The entities that are grouped - in a control domain are components of the control plane. + (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. + 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. + Management domain: [See Recommendation G.805] A management domain + defines a collection of managed objects which are grouped to meet + organizational requirements according to geography, technology, + policy or other structure, and for a number of functional areas such + as configuration, security, (FCAPS), for the purpose of providing + control in a consistent manner. Management domains can be disjoint, + contained or overlapping. As such the resources within an + administrative domain can be distributed into several possible + overlapping management domains. The same resource can therefore + belong to several management domains simultaneously, but a + management domain shall not cross the border of an administrative + domain. + +W.Alanqar et al. - Expires October 2004 16 + SNP: The SNP is a control plane abstraction that represents an + actual or potential transport plane resource. SNPs (in different + subnetwork partitions) may represent the same transport resource. A + one-to-one correspondence should not be assumed. Transport plane: provides bi-directional or unidirectional transfer 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. User Network Interface (UNI): interfaces are located between - protocol controllers between a user and a control domain. + protocol controllers between a user and a control domain. Note: + there is no routing function associated with a UNI reference point. -W.Alanqar et al. - Expires July 2004 15 +W.Alanqar et al. - Expires October 2004 17 -Appendix 2 - ASON Routing Terminology +Appendix 2: ASON Routing Terminology This document makes use of the following terms: 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 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 @@ -798,37 +852,39 @@ 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 hence possibly multiple layer networks), the RCs + multiple RAs (and possibly to multiple layer networks), the RCs accessing the RDB may share the routing information. - Link Resource Manager (LRM): supplies all the relevant component - and TE link information to the RC. It informs the RC about any state + 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. -W.Alanqar et al. - Expires July 2004 16 +W.Alanqar et al. - Expires October 2004 18 Full Copyright Statement - "Copyright (C) The Internet Society (2003). All Rights Reserved. + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78 and + except as set forth therein, the authors retain all their rights. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of @@ -840,11 +896,11 @@ The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. -W.Alanqar et al. - Expires July 2004 17 +W.Alanqar et al. - Expires October 2004 19