Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON)
draft-ietf-ccamp-gmpls-ason-routing-reqts-05

Network Working Group                           Deborah Brungard (ATT) 
Internet Draft                                                  Editor 
Category: Informational                                                
Expiration Date: April 2005                               October 2004 
    
    
             Requirements for Generalized MPLS (GMPLS) Routing  
             for Automatically Switched Optical Network (ASON) 
    
             draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt 
    
    
Status of this Memo 
    
   This document is an Internet-Draft and is subject to all provisions 
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each 
   author represents that any applicable patent or other IPR claims of 
   which he or she is aware have been or will be disclosed, and any of 
   which he or she become aware will be disclosed, in accordance with 
   RFC 3668. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that other 
   groups may also distribute working documents as Internet-Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six months 
   and may be updated, replaced, or obsoleted by other documents at any 
   time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt. 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
Copyright Notice 
    
   Copyright (C) The Internet Society (2004). All Rights Reserved. 
    
Abstract 
    
   The Generalized Multi-Protocol Label Switching (GMPLS) suite of 
   protocols has been defined to control different switching 
   technologies as well as different applications. These include support 
   for requesting Time Division Multiplexing (TDM) connections including 
   Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy 
   (SDH) and Optical Transport Networks (OTNs). 
    
   This document concentrates on the routing requirements on the GMPLS 
   suite of protocols to support the capabilities and functionalities 
   for an Automatically Switched Optical Network (ASON) as defined by 
   ITU-T.  
 
 
D.Brungard et al. - Expires April 2005                                1 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
Table of Contents 
    
   Status of this Memo .............................................. 1 
   Abstract ......................................................... 1 
   Table of Contents ................................................ 2 
   1. Contributors .................................................. 2 
   2. Conventions used in this document ............................. 2 
   3. Introduction .................................................. 2 
   4. ASON Routing Architecture and Requirements .................... 4 
   4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) ..... 5 
   4.2 Hierarchical Routing Information Dissemination ............... 5 
   4.3 Configuration ................................................ 7 
   4.3.1 Configuring the Multi-Level Hierarchy ...................... 7 
   4.3.2 Configuring RC Adjacencies ................................. 8 
   4.4 Evolution .................................................... 8 
   4.5 Routing Attributes ........................................... 8 
   4.5.1 Taxonomy of Routing Attributes ............................. 8 
   4.5.2 Commonly Advertised Information ............................ 9 
   4.5.3 Node Attributes ............................................ 9 
   4.5.4 Link Attributes ........................................... 10 
   5. Security Considerations ...................................... 11 
   6. Conclusions .................................................. 12 
   7. Acknowledgements ............................................. 13 
   8. References ................................................... 14 
   8.1 Normative References ........................................ 14 
   8.2 Informative References ...................................... 14 
   9. Author's Addresses ........................................... 14 
   Appendix 1: ASON Terminology .................................... 16 
   Appendix 2: ASON Routing Terminology ............................ 18 
   Intellectual Property Statement ................................. 19 
   Disclaimer of Validity .......................................... 19 
   Copyright Statement ............................................. 19 
 
1. Contributors 
    
   This document is the result of the CCAMP Working Group ASON Routing 
   Requirements design team joint effort. The following are the design 
   team member authors that contributed to the present document: 
    
   Wesam Alanqar (Sprint)  
   Deborah Brungard (ATT) 
   David Meyer (Cisco Systems) 
   Lyndon Ong (Ciena) 
   Dimitri Papadimitriou (Alcatel) 
   Jonathan Sadler (Tellabs) 
   Stephen Shew (Nortel) 
    
2. Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC 2119 [RFC2119]. 
 
 
D.Brungard et al. - Expires April 2005                                2 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
    
   While [RFC2119] describes interpretations of these key words in terms 
   of protocol specifications and implementations, they are used in this 
   document to describe design requirements for protocol extensions. 
    
3. Introduction 
    
   The Generalized Multi-Protocol Label Switching (GMPLS) suite of 
   protocols provides among other capabilities support for controlling 
   different switching technologies. These include support for 
   requesting TDM connections utilizing SONET/SDH (see ANSI T1.105/ITU-T 
   G.707, respectively) as well as Optical Transport Networks (OTN, see 
   ITU-T G.709). However, there are certain capabilities that are needed 
   to support the ITU-T G.8080 control plane architecture for 
   Automatically Switched Optical Network (ASON). Therefore, it is 
   desirable to understand the corresponding requirements for the GMPLS 
   protocol suite. The ASON control plane architecture is defined in 
   [G.8080], ASON routing requirements are identified in [G.7715], and 
   in [G.7715.1] for ASON link state protocols. These Recommendations 
   apply to all G.805 layer networks (e.g. SDH and OTN), and provide 
   protocol neutral functional requirements and architecture. 
    
   This document focuses on the routing requirements for the GMPLS suite 
   of protocols to support the capabilities and functionality of ASON 
   control planes. This document summarizes the ASON requirements using 
   ASON terminology. This document does not address GMPLS applicability 
   or GMPLS capabilities. Any protocol (in particular, routing) 
   applicability, design or suggested extensions is strictly outside the 
   scope of this document. ASON (Routing) terminology sections are 
   provided in Appendix 1 and 2.  
    
   The ASON routing architecture is based on the following assumptions: 
   - A network is subdivided based on operator decision and criteria  
     (e.g. geography, administration, and/or technology), the network  
     subdivisions are defined in ASON as Routing Areas (RAs).  
   - The routing architecture and protocols applied after the network  
     is subdivided is an operator's choice. A multi-level hierarchy of  
     RAs, as defined in ITU-T [G.7715] and [G.7715.1], provides for a  
     hierarchical relationship of RAs based on containment, i.e. child  
     RAs are always contained within a parent RA. The hierarchical  
     containment relationship of RAs provides for routing information  
     abstraction, thereby enabling scalable routing information  
     representation. The maximum number of hierarchical RA levels to be  
     supported is not specified (outside the scope). 
   - Within an ASON RA and for each level of the routing hierarchy,  
     multiple routing paradigms (hierarchical, step-by-step, source- 
     based), centralized or distributed path computation, and multiple  
     different routing protocols MAY be supported. The architecture  
     does not assume a one-to-one correspondence of a routing protocol  
     and a RA level and allows the routing protocol(s) used within 
     different RAs (including child and parent RAs) to be different.  
     The realization of the routing paradigm(s) to support the  
 
 
D.Brungard et al. - Expires April 2005                                3 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
     hierarchical levels of RAs is not specified. 
   - The routing adjacency topology (i.e. the associated Protocol  
     Controller (PC) connectivity) and transport topology is NOT  
     assumed to be congruent. 
   - The requirements support architectural evolution, e.g. a change in  
     the number of RA levels, as well as aggregation and segmentation  
     of RAs.  
    
   The description of the ASON routing architecture provides for a 
   conceptual reference architecture, with definition of functional 
   components and common information elements to enable end-to-end 
   routing in the case of protocol heterogeneity and facilitate 
   management of ASON networks. This description is only conceptual: no 
   physical partitioning of these functions is implied. 
 
4. ASON Routing Architecture and Requirements  
    
   The fundamental architectural concept is the RA and its related 
   functional components (see Appendix 2 on terminology). The routing 
   services offered by a RA are provided by a Routing Performer (RP). A 
   RP is responsible for a single RA, and it MAY be functionally 
   realized using distributed Routing Controllers (RC). The RC, itself, 
   MAY be implemented as a cluster of distributed entities (ASON refers 
   to the cluster as a Routing Control Domain (RCD)). The RC components 
   for a RA receive routing topology information from their associated 
   Link Resource Manager(s) (LRMs) and store this information in the 
   Routing Information Database (RDB). The RDB is replicated at each RC 
   bounded to the same RA, and MAY contain information about multiple 
   transport plane network layers. Whenever the routing topology 
   changes, the LRM informs the corresponding RC, which in turn updates 
   its associated RDB. In order to assure RDB synchronization, the RCs 
   co-operate and exchange routing information. Path computation 
   functions MAY exist in each RC, MAY exist on selected RCs within the 
   same RA, or MAY be centralized for the RA. 
    
   In this context, communication between RCs within the same RA is 
   realized using a particular routing protocol (or multiple protocols). 
   In ASON, the communication component is represented by the protocol 
   controller (PC) component(s) and the protocol messages are conveyed 
   over the ASON control plane's Signaling Control Network (SCN). The PC 
   MAY convey information for one or more transport network layers 
   (refer to Section 4.2 Note). The RC is protocol independent and RC 
   communications MAY be realized by multiple, different PCs within a 
   RA. 
    
   The ASON routing architecture defines a multi-level routing hierarchy 
   of RAs based on a containment model to support routing information 
   abstraction. [G.7715.1] defines the ASON hierarchical link state 
   routing protocol requirements for communication of routing 
   information within an RA (one level) to support hierarchical routing 
   information dissemination (including summarized routing information 
   for other levels). The communication between any of the other 
 
 
D.Brungard et al. - Expires April 2005                                4 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
   functional component(s) (e.g. SCN, LRM, and between RCDs (RC-RC 
   communication between RAs)), is outside the scope of [G.7715.1] 
   protocol requirements and, thus, is also outside the scope of this 
   document. 
    
   ASON Routing components are identified by identifiers that are drawn 
   from different name spaces (see [G.7715.1]). These are control plane 
   identifiers for transport resources, components, and SCN addresses. 
   The formats of those identifiers in a routing protocol realization 
   SHALL be implementation specific and outside the scope of this 
   document. 
    
   The failure of a RC, or the failure of communications between RCs, 
   and the subsequent recovery from the failure condition MUST NOT 
   disrupt calls in progress (i.e. already established) and their 
   associated connections. Calls being set up MAY fail to complete, and 
   the call setup service MAY be unavailable during recovery actions. 
    
4.1 Multiple Hierarchical Levels of ASON Routing Areas (RAs) 
    
   [G.8080] introduces the concept of Routing Area (RA) in reference to 
   a network subdivision. RAs provide for routing information 
   abstraction. Except for the single RA case, RAs are hierarchically 
   contained: a higher level (parent) RA contains lower level (child) 
   RAs that in turn MAY also contain RAs, etc. Thus, RAs contain RAs 
   that recursively define successive hierarchical RA levels. 
    
   However, the RA containment relationship describes only an 
   architectural hierarchical organization of RAs. It does not restrict 
   a specific routing protocol's realization (e.g. OSPF multi-areas, 
   path computation, etc.). Moreover, the realization of the routing 
   paradigm to support a hierarchical organization of RAs and the number 
   of hierarchical RA levels to be supported is routing protocol 
   specific and outside the scope of this document.  
    
   In a multi-level hierarchy of RAs, it is necessary to distinguish 
   among RCs for the different levels of the RA hierarchy. Before any 
   pair of RCs establishes communication, they MUST verify they are 
   bound to the same parent RA (see Section 4.2). A RA identifier (RA 
   ID) is required to provide the scope within which the RCs can 
   communicate. To distinguish between RCs bound to the same RA, an RC 
   identifier (RC ID) is required; the RC ID MUST be unique within its 
   containing RA. 
    
   A RA represents a partition of the data plane, and its identifier 
   (i.e. RA ID) is used within the control plane as a reference to the 
   data plane partition. Each RA within a carrier's network SHALL be 
   uniquely identifiable. RA IDs MAY be associated with a transport 
   plane name space whereas RC IDs are associated with a control plane 
   name space.  
    
4.2 Hierarchical Routing Information Dissemination 
 
 
D.Brungard et al. - Expires April 2005                                5 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
    
   Routing information can be exchanged between RCs bound to adjacent 
   levels of the RA hierarchy i.e. Level N+1 and N, where Level N 
   represents the RAs contained by Level N+1. The links connecting RAs 
   may be viewed as external links (inter-RA links), and the links 
   representing connectivity within a RA may be viewed as internal links 
   (intra-RA links). The external links to a RA at one level of the 
   hierarchy may be internal links in the parent RA. Intra-RA links of a 
   child RA MAY be hidden from the parent RA's view. 
    
   The physical location of RCs for adjacent RA levels, their 
   relationship and their communication protocol(s) are outside the 
   scope of this document. No assumption is made regarding how RCs 
   communicate between adjacent RA levels. If routing information is 
   exchanged between a RC, its parent, and its child RCs, it SHOULD 
   include reachability (see Section 4.5.3) and MAY include, upon policy 
   decision, node and link topology. Communication between RAs only 
   takes place between RCs with a parent/child relationship. RCs of one 
   RA never communicate with RCs of another RA at the same level. There 
   SHOULD not be any dependencies on the different routing protocols 
   used within a RA or in different RAs. 
    
   Multiple RCs bound to the same RA MAY transform (filter, summarize, 
   etc.) and then forward information to RCs at different levels. 
   However, in this case, the resulting information at the receiving 
   level must be self-consistent (i.e. ensure consistency between 
   transform operations performed on routing information at different 
   levels to ensure proper information processing). This MAY be achieved 
   using a number of mechanisms. 
    
   Note: there is no implied relationship between multi-layer transport 
   networks and multi-level routing. Implementations MAY support a 
   hierarchical routing topology (multi-level) with a single routing 
   protocol instance for multiple transport switching layers or a 
   hierarchical routing topology for one transport switching layer. 
    
   1. Type of Information Exchanged 
    
      The type of information flowing upward (i.e. Level N to Level  
      N+1) and the information flowing downward (i.e. Level N+1 to  
      Level N) are used for similar purposes, namely, the exchange of  
      reachability information and summarized topology information to  
      allow routing across multiple RAs. The summarization of topology  
      information may impact the accuracy of routing and may require  
      additional path calculation. 
    
      The following information exchanges are expected: 
       
      - Level N+1 visibility to Level N reachability and topology (or  
        upward information communication) allowing RC(s) at Level N+1  
        to determine the reachable endpoints from Level N. 
      - Level N visibility to Level N+1 reachability and topology (or  
 
 
D.Brungard et al. - Expires April 2005                                6 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
        downward information communication) allowing RC(s) bounded to a  
        RA at Level N to develop paths to reachable endpoints outside  
        of the RA.  
    
   2. Interactions between Upward and Downward Communication 
    
      When both upward and downward information exchanges contain     
      endpoint reachability information, a feedback loop could      
      potentially be created. Consequently, the routing protocol MUST  
      include a method to: 
       
      - prevent information propagated from a Level N+1 RA's RC into  
        the Level N RA's RC from being re-introduced into the Level N+1  
        RA's RC, and 
       
      - prevent information propagated from a Level N-1 RA's RC into  
        the Level N RA's RC from being re-introduced into the Level N-1  
        RA's RC. 
    
      The routing protocol SHALL differentiate the routing information  
      originated at a given level RA from derived routing information  
      (received from external RAs), even when this information is  
      forwarded by another RC at the same level. This is a necessary  
      condition to be fulfilled by routing protocols to be loop free. 
    
   3. Method of Communication 
    
      Two approaches exist for communication between Level N and N+1. 
    
      - The first approach places an instance of a Level N routing  
        function and an instance of a Level N+1 routing function in the  
        same system. The communications interface is within a single  
        system and is thus not an open interface subject to  
        standardization. However, information re-advertisement or  
        leaking MUST be performed in a consistent manner to ensure  
        interoperability and basic routing protocol correctness (e.g.  
        cost/metric value). 
    
      - The second approach places the Level N routing function on a  
        separate system from the Level N+1 routing function. In this  
        case, a communication interface must be used between the    
        systems containing the routing functions for different levels.     
        This communication interface and mechanisms are outside the  
        scope of this document.  
    
4.3 Configuration 
    
4.3.1 Configuring the Multi-Level Hierarchy  
    
   The RC MUST support static (i.e. operator assisted) and MAY support 
   automated configuration of the information describing its 
   relationship to its parent and its child within the hierarchical 
 
 
D.Brungard et al. - Expires April 2005                                7 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
   structure (including RA ID and RC ID). When applied recursively, the 
   whole hierarchy is thus configured. 
    
4.3.2 Configuring RC Adjacencies 
    
   The RC MUST support static (i.e. operator assisted) and MAY support 
   automated configuration of the information describing its associated 
   adjacencies to other RCs within a RA. The routing protocol SHOULD 
   support all the types of RC adjacencies described in Section 9 of 
   [G.7715]. The latter includes congruent topology (with distributed  
   RC) and hubbed topology (e.g. note that the latter does not 
   automatically imply designated RC).  
    
4.4 Evolution 
    
   The containment relationships of RAs may change, motivated by events 
   such as mergers, acquisitions, and divestitures.  
    
   The routing protocol SHOULD be capable of supporting architectural 
   evolution in terms of number of hierarchical levels of RAs, as well 
   as aggregation and segmentation of RAs. RA ID uniqueness within an 
   administrative domain may facilitate these operations. The routing 
   protocol is not expected to automatically initiate and/or execute 
   these operations. Reconfiguration of the RA hierarchy may not disrupt 
   calls in progress, though calls being set up may fail to complete, 
   and the call setup service may be unavailable during reconfiguration 
   actions. 
    
4.5 Routing Attributes 
    
   Routing for transport networks is performed on a per layer basis, 
   where the routing paradigms MAY differ among layers and within a 
   layer. Not all equipment supports the same set of transport layers or 
   the same degree of connection flexibility at any given layer. A 
   server layer trail may support various clients, involving different 
   adaptation functions. Additionally, equipment may support variable 
   adaptation functionality, whereby a single server layer trail 
   dynamically supports different multiplexing structures. As a result, 
   routing information MAY include layer specific, layer independent, 
   and client/server adaptation information. 
    
4.5.1 Taxonomy of Routing Attributes 
    
   Attributes can be organized according to the following categories: 
    
   - Node related or link related 
    
   - Provisioned, negotiated or automatically configured  
    
   - Inherited or layer specific (client layers can inherit some  
     attributes from the server layer while other attributes like    
     Link Capacity are specified by layer). 
 
 
D.Brungard et al. - Expires April 2005                                8 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
    
   (Component) link attributes MAY be statically or automatically 
   configured for each transport network layer. This may lead to 
   unnecessary repetition. Hence, the inheritance property of attributes 
   MAY also be used to optimize the configuration process. 
    
   ASON uses the term, SubNetwork Point (SNP), for the control plane 
   representation of a transport plane resource. The control plane 
   representation and transport plane topology is NOT assumed to be 
   congruent, the control plane representation SHALL not be restricted 
   by the physical topology. The relational grouping of SNPs for routing 
   is termed a SNP Pool (SNPP). The routing function understands 
   topology in terms of SNPP links. Grouping MAY be based on different 
   link attributes (e.g., SRLG information, link weight, etc). 
    
   Two RAs may be linked by one or more SNPP links. Multiple SNPP links 
   may be required when component links are not equivalent for routing 
   purposes with respect to the RAs they are attached to, or to the 
   containing RA, or when smaller groupings are required. 
    
4.5.2 Commonly Advertised Information 
    
   Advertisements MAY contain the following common set of information 
   regardless of whether they are link or node related:  
   - RA ID of the RA to which the advertisement is bounded 
   - RC ID of the entity generating the advertisement 
   - Information to uniquely identify advertisements 
   - Information to determine whether an advertisement has been updated 
   - Information to indicate when an advertisement has been derived  
     from a different level RA. 
    
4.5.3 Node Attributes 
    
   All nodes belong to a RA, hence, the RA ID can be considered an 
   attribute of all nodes. Given that no distinction is made between 
   abstract nodes and those that cannot be decomposed any further, the 
   same attributes MAY be used for their advertisement. In the following 
   tables, Capability refers to the level of support required in the 
   realization of a link state routing protocol, whereas Usage refers to 
   the degree of operational control that SHOULD be available to the 
   operator. 
    
   The following Node Attributes are defined: 
    
       Attribute        Capability      Usage 
       -----------      -----------     --------- 
       Node ID          REQUIRED        REQUIRED 
       Reachability     REQUIRED        OPTIONAL 
    
                Table 1. Node Attributes 
    

 
 
D.Brungard et al. - Expires April 2005                                9 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
   Reachability information describes the set of endpoints that are 
   reachable by the associated node. It MAY be advertised as a set of 
   associated external (e.g. UNI) address/address prefixes or a set of 
   associated SNPP link IDs/SNPP ID prefixes, the selection of which 
   MUST be consistent within the applicable scope. These are control 
   plane identifiers, the formats of these identifiers in a protocol 
   realization is implementation specific and outside the scope of this 
   document. 
    
   Note: no distinction is made between nodes that may have further 
   internal details (i.e., abstract nodes) and those that cannot be 
   decomposed any further. Hence the attributes of a node are not 
   considered only as single switch attributes but MAY apply to a node 
   at a higher level of the hierarchy that represents a sub-network. 
    
4.5.4 Link Attributes 
    
   The following Link Attributes are defined: 
    
       Link Attribute                   Capability      Usage 
       ---------------                  -----------     --------- 
       Local SNPP link ID               REQUIRED        REQUIRED 
       Remote SNPP link ID              REQUIRED        REQUIRED 
       Layer Specific Characteristics   see Table 3  
    
                         Table 2. Link Attributes 
    
   The SNPP link ID MUST be sufficient to uniquely identify (within the 
   Node ID scope) the corresponding transport plane resource taking into 
   account separation of data and control planes (see Section 4.5.1, the 
   control plane representation and transport plane topology is not 
   assumed to be congruent). The SNPP link ID format is routing protocol 
   specific.  
    
   Note: when the remote end of a SNPP link is located outside of the 
   RA, the remote SNPP link ID is OPTIONAL. 
    
   The following link characteristic attributes are defined: 
    
   - Signal Type: This identifies the characteristic information of the  
     layer network. 
    
   - Link Weight: The metric indicating the relative desirability of a  
     particular link over another e.g. during path computation.  
    
   - Resource Class: This corresponds to the set of administrative  
     groups assigned by the operator to this link. A link MAY belong to  
     zero, one or more administrative groups. 
    
   - Connection Types: This attribute identifies whether the local SNP  
     represents a Termination Connection Point (CP), a Connection Point  
     (CP), or can be flexibly configured as a TCP. 
 
 
D.Brungard et al. - Expires April 2005                                10 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
    
   - Link Capacity: This provides the sum of the available and  
     potential bandwidth capacity for a particular network transport  
     layer. Other capacity measures MAY be further considered. 
    
   - Link Availability: This represents the survivability capability  
     such as the protection type associated with the link. 
    
   - Diversity Support: This represents diversity information such as  
     the SRLG information associated with the link.  
    
   - Local Adaptation Support: This indicates the set of client layer  
     adaptations supported by the TCP associated with the Local SNPP. 
     This is only applicable when the local SNP represents a TCP or can  
     be flexibly configured as a TCP. 
    
        Link Characteristics            Capability      Usage 
        -----------------------         ----------      --------- 
        Signal Type                     REQUIRED        OPTIONAL 
        Link Weight                     REQUIRED        OPTIONAL 
        Resource Class                  REQUIRED        OPTIONAL 
        Local Connection Types          REQUIRED        OPTIONAL 
        Link Capacity                   REQUIRED        OPTIONAL 
        Link Availability               OPTIONAL        OPTIONAL 
        Diversity Support               OPTIONAL        OPTIONAL 
        Local Adaptation support        OPTIONAL        OPTIONAL 
    
                       Table 3. Link Characteristics 
    
   Note: separate advertisements of layer specific attributes MAY be 
   chosen. However, this may lead to unnecessary duplication. This can 
   be avoided using the inheritance property, so that the attributes 
   derivable from the local adaptation information do not need to be 
   advertised. Thus, an optimization MAY be used when several layers are 
   present by indicating when an attribute is inheritable from a server 
   layer. 
    
5. Security Considerations 
    
   ASON routing protocol MUST deliver the operational security 
   objectives where required. The overall security objectives (defined 
   in ITU-T Recommendation M.3016) of confidentiality, integrity, 
   accountability may take on varying level of importance. These 
   objectives do not necessarily imply requirements on the routing 
   protocol itself, and MAY be met by other established means. 
    
   Note: a threat analysis of a proposed routing protocol SHOULD address 
   masquerade, eavesdropping, unauthorized access, loss or corruption of 
   information (includes replay attacks), repudiation, forgery and 
   denial of service attacks.  
    
    
 
 
D.Brungard et al. - Expires April 2005                                11 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
6. Conclusions 
    
   The description of the ASON routing architecture and components is 
   provided in terms of routing functionality. This description is only 
   conceptual: no physical partitioning of these functions is implied. 
    
   In summary, the ASON routing architecture assumes: 
   - A network is subdivided into ASON RAs, which MAY support multiple  
     routing protocols, no one-to-one relationship SHALL be assumes. 
   - Routing Controllers (RC) provide for the exchange of routing  
     information (primitives) for the RA. The RC is protocol  
     independent and MAY be realized by multiple, different protocol  
     controllers within a RA. The routing information exchanged between  
     RCs SHALL be subject to policy constraints imposed at reference  
     points (External- and Internal-NNI). 
   - In a multi-level RA hierarchy based on containment, communication 
     between RCs of different RAs only happens when there is a parent/ 
     child relationship between the RAs. RCs of child RAs never  
     communicate with the RCs of other child RAs. There SHOULD not be  
     any dependencies on the different routing protocols used within a  
     child RA and that of its parent. The routing information exchanged  
     within the parent RA SHALL be independent of both the routing  
     protocol operating within a child RA, and any control distribution  
     choice(s), e.g. centralized, fully distributed. 
   - For a RA, the set of RCs is referred to as an ASON routing  
     (control) domain. The routing information exchanged between  
     routing domains (inter-RA, i.e. inter-domain) SHALL be independent  
     of both the intra-domain routing protocol(s), and the intra-domain  
     control distribution choice(s), e.g. centralized, fully    
     distributed. RCs bounded to different RA levels MAY be co-located  
     within the same physical element or physically distributed. 
   - The routing adjacency topology (i.e. the associated PC    
     connectivity topology) and the transport network topology SHALL  
     NOT be assumed to be congruent. 
   - The routing topology SHALL support multiple links between nodes  
     and RAs. 
    
   In summary, the following functionality is expected from GMPLS 
   routing to instantiate the ASON hierarchical routing architecture 
   realization (see [G.7715] and [G.7715.1]):   
   - RAs SHALL be uniquely identifiable within a carrier's network,  
     each having a unique RA ID within the carrier's network. 
   - Within a RA (one level), the routing protocol SHALL support  
     dissemination of hierarchical routing information (including  
     summarized routing information for other levels) in support of an  
     architecture of multiple hierarchical levels of RAs; the number of  
     hierarchical RA levels to be supported by a routing protocol is  
     implementation specific. 
   - The routing protocol SHALL support routing information based on a  
     common set of information elements as defined in [G.7715] and  
     [G.7715.1], divided between attributes pertaining to links and  
     abstract nodes (each representing either a sub-network or simply a  
 
 
D.Brungard et al. - Expires April 2005                                12 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
     node). [G.7715] recognizes that the manner in which the routing  
     information is represented and exchanged will vary with the  
     routing protocol used. 
   - The routing protocol SHALL converge such that the distributed RDBs  
     become synchronized after a period of time. 
    
   To support hierarchical routing information dissemination within an 
   RA, the routing protocol MUST deliver: 
   - Processing of routing information exchanged between adjacent  
     levels of the hierarchy (i.e. Level N+1 and N) including  
     reachability and upon policy decision summarized topology  
     information. 
   - Self-consistent information at the receiving level resulting from 
     any transformation (filter, summarize, etc.) and forwarding of 
     information from one RC to RC(s) at different levels when multiple 
     RCs bound to a single RA. 
   - A mechanism to prevent re-introduction of information propagated 
     into the Level N RA's RC back to the adjacent level RA's RC from 
     which this information has been initially received. 
    
   In order to support operator assisted changes in the containment 
   relationships of RAs, the routing protocol SHALL support evolution in 
   terms of number of hierarchical levels of RAs. For example: support 
   of non-disruptive operations such as adding and removing RAs at the 
   top/bottom of the hierarchy, adding or removing a hierarchical level 
   of RAs in or from the middle of the hierarchy, as well as aggregation 
   and segmentation of RAs. The number of hierarchical levels to be 
   supported is routing protocol specific, and reflects a containment 
   relationship e.g. a RA insertion involves supporting a different 
   routing protocol domain in a portion of the network.  
    
   Reachability information (see Section 4.5.3) of the set of endpoints 
   reachable by a node may be advertised either as a set of UNI 
   Transport Resource addresses/ address prefixes, or a set of 
   associated SNPP link IDs/SNPP link ID prefixes, assigned and selected 
   consistently in their applicability scope. The formats of the control 
   plane identifiers in a protocol realization are implementation 
   specific. Use of a routing protocol within a RA should not restrict 
   the choice of routing protocols for use in other RAs (child or 
   parent). 
    
   As ASON does not restrict the control plane architecture choice used, 
   either a co-located architecture or a physically separated 
   architecture may be used. A collection of links and nodes such as a 
   sub-network or RA MUST be able to represent itself to the wider 
   network as a single logical entity with only its external links 
   visible to the topology database. 
    
7. Acknowledgements 
    

 
 
D.Brungard et al. - Expires April 2005                                13 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
   The authors would like to thank Kireeti Kompella for having initiated 
   the proposal of an ASON Routing Requirement Design Team and the ITU-T 
   SG15/Q14 for their careful review and input. 
    
8. References 
    
8.1 Normative References 
    
   [RFC2026]    S.Bradner, "The Internet Standards Process --          
                Revision 3", BCP 9, RFC 2026, October 1996.            
    
   [RFC2119]    S.Bradner, "Key words for use in RFCs to Indicate      
                Requirement Levels", BCP 14, RFC 2119, March 1997.  
    
   [RFC3667]    S.Bradner, "IETF Rights in Contributions", BCP 78, 
                RFC 3667, February 2004. 
                 
   [RFC3668]    S.Bradner, Ed., "Intellectual Property Rights in IETF 
                Technology", BCP 79, RFC 3668, February 2004.    
 
8.2 Informative References 
    
   For information on the availability of the following documents,  
   please see http://www.itu.int:  
    
   [G.7715]     ITU-T Rec. G.7715/Y.1306, "Architecture and    
                Requirements for the Automatically Switched Optical  
                Network (ASON)," June 2002. 
    
   [G.7715.1]   ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing 
                Architecture and Requirements for Link State Protocols," 
                November 2003. 
    
   [G.8080]     ITU-T Rec. G.8080/Y.1304, "Architecture for the        
                Automatically Switched Optical Network (ASON),"        
                November 2001 (and Revision, January 2003). 
                 
9. Author's Addresses 
    
   Wesam Alanqar (Sprint)                  
   EMail: wesam.alanqar@mail.sprint.com  
    
   Deborah Brungard (AT&T) 
   Rm. D1-3C22 - 200 S. Laurel Ave. 
   Middletown, NJ 07748, USA 
   Phone: +1 732 4201573 
   EMail: dbrungard@att.com 
    
   David Meyer (Cisco Systems) 
   EMail: dmm@1-4-5.net 
    
   Lyndon Ong (Ciena Corporation) 
 
 
D.Brungard et al. - Expires April 2005                                14 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
   5965 Silver Creek Valley Rd,  
   San Jose, CA 95128, USA 
   Phone: +1 408 8347894 
   EMail: lyong@ciena.com 
    
   Dimitri Papadimitriou (Alcatel) 
   Francis Wellensplein 1,  
   B-2018 Antwerpen, Belgium 
   Phone: +32 3 2408491 
   EMail: dimitri.papadimitriou@alcatel.be 
    
   Jonathan Sadler 
   1415 W. Diehl Rd 
   Naperville, IL 60563 
   EMail: jonathan.sadler@tellabs.com 
    
   Stephen Shew (Nortel Networks) 
   PO Box 3511 Station C 
   Ottawa, Ontario, CANADA K1Y 4H7 
   Phone: +1 613 7632462 
   EMail: sdshew@nortelnetworks.com 

 
 
D.Brungard et al. - Expires April 2005                                15 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
Appendix 1: ASON Terminology 
    
   This document makes use of the following terms: 
    
   Administrative domain: (see Recommendation G.805) for the purposes of 
   [G7715.1] an administrative domain represents the extent of resources 
   which belong to a single player such as a network operator, a service 
   provider, or an end-user. Administrative domains of different players 
   do not overlap amongst themselves. 
    
   Adaptation function: (see Recommendation G.805) A "transport 
   processing function" which processes the client layer information for 
   transfer over a server layer trail. 
    
   Client/Server relationship: The association between layer networks 
   that is performed by an "adaptation" function to allow the link 
   connection in the client layer network to be supported by a trail in 
   the server layer network. 
    
   Control plane: performs the call control and connection control 
   functions. Through signaling, the control plane sets up and releases 
   connections, and may restore a connection in case of a failure. 
    
   (Control) Domain: represents a collection of (control) entities that 
   are grouped for a particular purpose. The control plane is subdivided 
   into domains matching administrative domains. Within an 
   administrative domain, further subdivisions of the control plane are 
   recursively applied. A routing control domain is an abstract entity 
   that hides the details of the RC distribution. 
    
   External NNI (E-NNI): interfaces are located between protocol 
   controllers between control domains. 
    
   Internal NNI (I-NNI): interfaces are located between protocol 
   controllers within control domains. 
    
   Link: (see Recommendation G.805) a "topological component" which 
   describes a fixed relationship between a "subnetwork" or "access 
   group" and another "subnetwork" or "access group". Links are not 
   limited to being provided by a single server trail.  
    
   Management plane: performs management functions for the Transport 
   Plane, the control plane and the system as a whole. It also provides 
   coordination between all the planes. The following management 
   functional areas are performed in the management plane: performance, 
   fault, configuration, accounting and security management 
    
   Management domain: (see Recommendation G.805) a management domain 
   defines a collection of managed objects which are grouped to meet 
   organizational requirements according to geography, technology, 
   policy or other structure, and for a number of functional areas such 
   as configuration, security, (FCAPS), for the purpose of providing 
 
 
D.Brungard et al. - Expires April 2005                                16 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
   control in a consistent manner. Management domains can be disjoint, 
   contained or overlapping. As such the resources within an 
   administrative domain can be distributed into several possible 
   overlapping management domains. The same resource can therefore 
   belong to several management domains simultaneously, but a management 
   domain shall not cross the border of an administrative domain. 
    
   Multiplexing: (see Recommendation G.805) Multiplexing techniques are 
   used to combine client layer signals. The many-to-one relationship 
   represents the case of several link connections of client layer 
   networks supported by one server layer trail at the same time.  
    
   Subnetwork Point (SNP): The SNP is a control plane abstraction that 
   represents an actual or potential transport plane resource. SNPs (in 
   different subnetwork partitions) may represent the same transport 
   resource. A one-to-one correspondence should not be assumed. 
    
   Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together 
   for the purposes of routing. 
    
   Termination Connection Point (TCP): A TCP represents the output of a 
   Trail Termination function or the input to a Trail Termination Sink 
   function. 
    
   Trail: (see Recommendation G.805) A "transport entity" which consists 
   of an associated pair of "unidirectional trails" capable of 
   simultaneously transferring information in opposite directions 
   between their respective inputs and outputs. 
 
   Transport plane: provides bi-directional or unidirectional transfer 
   of user information, from one location to another. It can also 
   provide transfer of some control and network management information. 
   The Transport Plane is layered; it is equivalent to the Transport 
   Network defined in G.805 Recommendation. 
    
   User Network Interface (UNI): interfaces are located between protocol 
   controllers between a user and a control domain. Note: there is no 
   routing function associated with a UNI reference point.  
    
   Variable adaptation function: A single server layer trail may 
   dynamically support different multiplexing structures i.e. link 
   connections for multiple client layer networks. 

 
 
D.Brungard et al. - Expires April 2005                                17 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
Appendix 2: ASON Routing Terminology 
    
   This document makes use of the following terms: 
    
   Routing Area (RA): a RA represents a partition of the data plane and 
   its identifier is used within the control plane as the representation 
   of this partition. Per [G.8080] a RA is defined by a set of sub-
   networks, the links that interconnect them, and the interfaces 
   representing the ends of the links exiting that RA. A RA may contain 
   smaller RAs inter-connected by links. The limit of subdivision 
   results in a RA that contains two sub-networks interconnected by a 
   single link. 
    
   Routing Database (RDB): repository for the local topology, network 
   topology, reachability, and other routing information that is updated 
   as part of the routing information exchange and may additionally 
   contain information that is configured. The RDB may contain routing 
   information for more than one Routing Area (RA). 
    
   Routing Components: ASON routing architecture functions. These 
   functions can be classified as protocol independent (Link Resource 
   Manager or LRM, Routing Controller or RC) and protocol specific 
   (Protocol Controller or PC).  
    
   Routing Controller (RC): handles (abstract) information needed for 
   routing and the routing information exchange with peering RCs by 
   operating on the RDB. The RC has access to a view of the RDB. The RC 
   is protocol independent. 
    
   Note: Since the RDB may contain routing information pertaining to 
   multiple RAs (and possibly to multiple layer networks), the RCs 
   accessing the RDB may share the routing information. 
    
   Link Resource Manager (LRM): supplies all the relevant component and 
   TE link information to the RC. It informs the RC about any state 
   changes of the link resources it controls. 
    
   Protocol Controller (PC): handles protocol specific message exchanges 
   according to the reference point over which the information is 
   exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC. 
   The PC function is protocol dependent. 
    

 
 
D.Brungard et al. - Expires April 2005                                18 


draft-ietf-ccamp-gmpls-ason-routing-reqts-05.txt            October 2004 
 
 
Intellectual Property Statement 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights.  Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard. Please address the information to the IETF at 
   ietf-ipr@ietf.org. 
    
Disclaimer of Validity 
    
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
Copyright Statement 
    
   Copyright (C) The Internet Society (2004). This document is subject 
   to the rights, licenses and restrictions contained in BCP 78, and 
   except as set forth therein, the authors retain all their rights. 
 
Acknowledgment 
 
   Funding for the RFC Editor function is currently provided by the 
   Internet Society. 
    

 
 
D.Brungard et al. - Expires April 2005                                19