CCAMP Working Group                             Wesam Alanqar (Sprint)
Internet Draft                                  Deborah Brungard (ATT)
Category: Informational                     Dave                    David Meyer (Cisco Systems)
                                                    Lyndon Ong (Ciena)
Expiration Date: July October 2004          Dimitri Papadimitriou (Alcatel)
                                             Jonathan Sadler (Tellabs)
                                                 Stephen Shew (Nortel)

                                                         February

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

Abstract

   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 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. RFC 2119
   [RFC2119].

3. Introduction

   The GMPLS suite of protocols provides among other capability 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 (see
   (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 the 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
   [G.8080], ASON routing requirements are identified in [G.7715] [G.7715], and refined
   in [G.7715.1] for ASON link state architectures. protocols. These
   recommendations provide functional requirements Recommendations
   apply to all G.805 layer networks (e.g. SDH and OTN), and architecture,
   they provide a
   protocol neutral approach. 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 This document summarizes the ASON requirements for
   using ASON terminology. This document does not address 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
   applicability or GMPLS capabilities. Any protocol (in particular,
   routing) applicability, design or suggested protocol extensions is strictly
   outside the scope of this document. An ASON (Routing) terminology section is
   sections are provided in Appendix 1 and Appendix 2.

   The ASON model distinguishes reference points (representing points
   of information exchange) defined (1) between an administrative
   domain routing architecture is based on the following assumptions:
   - A network is subdivided based on operator decision 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 criteria
     (e.g. geography, administration, and/or technology), 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.

W.Alanqar et al. - Expires July 2004                                 2
   The term routing information refers to the abstract representation
   of network routing related information such
     subdivisions are defined in ASON 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. Areas (RAs).
   - The ASON routing architecture is based on and protocols applied after the following assumptions:
   - A carrier's network
     is subdivided is an operator's choice. A multi-level hierarchy of
     RAs, as Routing Areas (RAs). Each RA
     shall be uniquely identifiable 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 carrier's network (i.e.
     administrative domain). parent RA. The hierarchical
     containment relationship of RAs partitioning provide provides 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.
     representation. 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 maximum number of hierarchical RA levels to be
     supported is routing protocol
     implementation specific.
   - support hierarchical routing information dissemination including
     summarized routing information NOT specified (outside the scope).
   - support for multiple links between nodes (and between RAs) Within an ASON RA and for
     link and node diversity
   - support architectural evolution in terms each level of the number of levels
     of hierarchies, aggregation routing hierarchy,
     multiple routing paradigms (hierarchical, step- by-step, source-
     based), centralized or distributed path computation, and segmentation of RAs
   - support multiple
     different routing information based on protocols MAY be supported. The architecture
     does NOT assume a common set one-to-one correspondence of information
     elements as defined in [G.7715] and [G.7715.1], divided between
     attributes pertaining to links and abstract nodes (each
     representing either a sub-network or simply a node). [G.7715]
     recognizes that the manner in which the routing information is
     represented and exchanged will vary with the routing protocol
     used.

   Also,
     and a RA level and allows the behaviour of GMPLS routing is expected protocol(s) used within
     different RAs (including child and parent RAs) to be such that:
   - it is scalable with respect different.
     The realization of the routing paradigm(s) to support the number
     hierarchical levels of links, nodes and RAs is NOT specified.
   - in response to a The routing event (e.g. adjacency topology update, reachability

W.Alanqar et al. - Expires July 2004                                 3
     update), it delivers convergence (i.e. the associated Protocol
     Controller (PC) connectivity) and damping against flapping transport topology is NOT
     assumed to be congruent.
   - it fulfils The requirements support architectural evolution, e.g. a change in
     the operational security objectives where required

4. ASON Requirements for GMPLS Routing 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 (see Appendix 2) is
   provided and common information elements to enable end-to-end
   routing in terms the case of routing functionality. protocol heterogeneity and facilitate
   management of ASON networks. This description is only conceptual: no
   physical partitioning of these functions is implied.

W.Alanqar et al. - Expires October 2004                              3

4. ASON Routing Architecture and Requirements

   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 Controller (RC) Control Domain (RCD)). The RC components
   for a RA receive routing topology 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
   bounded to 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) 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 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. Moreover, as [G7715.1] states layers (refer to Section 4.2 Note). The RC is protocol
   independent and
   illustrates in its Figure 1, 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
   deals exclusively with the PC to PC for communication of the (RC)
   routing information; therefore any information within an RA (one level) to support hierarchical
   routing information dissemination (including summarized routing
   information for other communication levels). The Communication between any of the
   other functional component(s) (e.g. SC, LRM) 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.

   Note: the RC can be thought of as the function processing the TE
   database populated

   ASON Routing components are identified by the link local/remote component and TE links
   (LRM) identifiers that are drawn
   from different name spaces (see [G.7715.1]). These are control plane
   identifiers for transport resources, components, and by the network wide TE links through the PC which
   processes the SCN addresses.
   The formats of those identifiers in a routing protocol realization
   SHALL be implementation specific routing exchanges. and outside the scope of this
   document.

   The SCN
   corresponds to failure of a RC, or the IP control plane topology enabling routing
   exchanges failure of communications between GMPLS controllers (i.e. RCs,
   and the routing adjacencies). subsequent recover from the failure condition MUST NOT

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 of ASON Routing Areas (RAs)

   [G.8080] introduces the concept of Routing Area (RA). (RA) in reference to
   a network subdivision. RAs provide for routing information abstraction, thereby enabling scalable
   routing information representation.
   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 routing RA levels.

   However, the RA containment relationship describes only an
   architectural hierarchical organization of RAs. It does not restrict
   the
   a specific routing protocol protocol's realization (e.g. OSPF multi-areas,
   path computation, etc.). Moreover, the realization of the routing
   paradigm to support a hierarchical routing organization of RAs and the
   number of

W.Alanqar et al. - Expires July 2004                                 4 hierarchical RA levels to be supported is routing protocol
   specific and outside the scope of this document.

   ASON routing components are identified by values that MAY be drawn
   from several identifier spaces (see [G.7715.1]). The use of
   identifiers in a routing protocol realization is implementation
   specific and outside the scope of this document.

   In a multi-level routing hierarchy, hierarchy of RAs, it is necessary to distinguish
   among RCs within a level and RCs at for the different levels of the routing RA hierarchy. Before any
   pair of RCs establishes communication, they MUST verify they belong 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 within bounded to the same RA, an
   RC identifier (RC ID) is required; the RC ID must 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 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 RCs bounded to adjacent
   levels of the
   routing 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, links (inter-RA links), and the links
   representing connectivity within an a RA MAY be viewed as internal links.
   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 for adjacent RA levels, their
   relationship and their communication protocol 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

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.

   Multiple 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.

   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; self-consistent; this MAY be achieved using
   a number of mechanisms.

   Note: there is no implied relationship between multi-layer transport
   networks and multi-level routing. The former implies Implementations may support a
   hierarchical routing topology (multi-level) with a single routing
   protocol instance for multiple transport switching layers whereas the latter implies or a
   hierarchical routing topology for one transport switching layer.

4.2.1 Communication between Adjacent Routing Levels

   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 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 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 RA's RC into
        the Level N RA RA's RC to be re-introduced into the Level N+1 RA, RA's
        RC, and

      - prevent information propagated from a Level N-1 RA RA's RC into
        the Level N RA RA's RC to be re-introduced into the Level N-1 RA. RA's

W.Alanqar et al. - Expires October 2004                              6
        RC.

      The routing protocol is required to SHALL differentiate the routing information
      originated at a given level RA from the one derived
      using the routing information received
      (received from its external RAs
      (regardless of the level of RAs), even when this information is
      forwarded by another RC at the corresponding RCs). same level. This is a necessary
      condition to be fulfilled by routing protocols to be loop free.

      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).

   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

4.3 Configuration

4.3.1 Configuring the Routing 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
   structure (including RA ID and RC ID). When applied recursively, the
   whole hierarchy is thus configured.

4.2.3

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 associated
   PC adjacencies to other RCs within a 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 (with (e.g. note that
   the latter does not automatically imply designated RC).

4.3

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, 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 Reconfiguration of the RA hierarchy MAY not
   disrupt calls in progress, though calls being set up may fail to
   complete, and RAs

   See Section 4.5.1 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 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 MAY be statically or automatically
   configured for each transport network layer. This may lead to
   unnecessary repetition. Hence, the inheritance property of
   attributes can MAY also be used to optimize the configuration process.

   TE links are configured through

   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 component 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 SNPP links. Multiple TE SNPP links may
   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 different level RA.

4.5.3 Node Attributes

   All nodes belong to a RA, hence 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 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 external (e.g. UNI) address/address prefixes or a set of
   associated TE SNPP link IDs,
   consistently assigned IDs/SNPP ID prefixes, the selection of which
   MUST be consistent within an administrative domain. 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 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 SNPP link ID               REQUIRED        REQUIRED

W.Alanqar et al. - Expires October 2004                              9
       Remote TE SNPP link ID              REQUIRED        REQUIRED
       TE Link
       Layer Specific Characteristics   see Table 3

                Table 2. Link Attributes

   The TE SNPP link ID must name MUST be sufficient to uniquely identify the
   corresponding transport plane resource taking into account
   separation of data and control planes. control planes (see Section 4.5.1, the
   control plane representation and transport plane topology is not
   assumed to be congruent). The TE SNPP link ID format is routing
   protocol specific.

   Note: when the remote end of a TE SNPP link is located outside of the
   RA, the remote TE SNPP link ID is OPTIONAL.

   The following TE 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 attribute identifies whether the local
     component link is at SNP
     represents a border TCP, CP, or within an LSP region (see [HIER]) 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 TCP associated to with the local TE link. Local SNPP.
     This can is only exist applicable when the "Local Connection
     Type" indicates crossing of an LSP Region local SNP represents a TCP or can
     be flexibly
     assigned to be at configured as a border or within an LSP region (see [HIER]).

        TE link 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

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 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. Backward Compatibility

   Any particular realization Security Considerations

   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.

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 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 ASON routing requirements MUST RCs of other child RAs. There SHOULD not be
   backward compatible with any dependencies
     on the considered different routing protocol(s).

   Backward compatibility means protocols used within a child RA and that at any level
     of the its parent. The routing
   hierarchy, nodes, some of which support information exchanged within the requirements described
   in this document, and some of which do not, MUST still parent
     RA SHALL be capable to
   operate as mandated by independent of both the OSPF, IS-IS, and/or IDR IETF WG routing protocol operating
     within a child RA, and their
   corresponding GMPLS extensions (as mandated by any control distribution choice(s), e.g.
     centralized, fully distributed.
   - For a RA, the CCAMP IETF WG).

   Additionally, nodes (that do not support these requirements and) are
   made part set of a multi-level RCs is referred to as an ASON routing hierarchy from their containing
   RA(s), must be capable of:
   - rejecting (or ignoring) any incoming
     (control) domain. The routing information that
     would exchanged between
     routing domains (inter-RA, i.e. inter-domain) SHALL be addressed to them in a way that is not detrimental to independent
     of both the
     network as a whole
   - communicating (at a given level) with any other node located
     at 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 level and that implements these requirements
   This assumes that such nodes do not communicate directly either with
   lower physical element or upper level nodes.

   Note: backward compatibility with physically distributed.
   - The routing protocols is a protocol
   requirement defined in adjacency topology (i.e. the IETF context. associated PC

W.Alanqar et al. - Expires July October 2004                                10

6. Security Considerations

   ASON routing protocol MUST deliver                             11
     connectivity topology) and the operational security
   objectives where required.

7. Conclusions

   This section captures 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 identified ASON hierarchical routing requirements 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 missing capabilities from carrier's network.
   - Within a RA (one level), the GMPLS routing protocols (e.g.
   OSPF, IS-IS).

   The GMPLS routing protocol is required to SHALL support multiple
   hierarchical levels
     dissemination of RAs and hierarchical routing information
   dissemination including (including
     summarized routing information. However, information for other levels) in support of an
     architecture of multiple hierarchical levels of RAs; the number of
     hierarchical RA levels to be supported is by a routing protocol is
     implementation specific. This implies
   - 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 GMPLS manner in which the routing
     information is represented and exchanged will vary with the
     routing protocol must 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 routing hierarchy (i.e. Level N+1 and N) including
     reachability and upon policy decision summarized topology
     information
   - when multiple RCs within 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 self-
     consistent
   - a mechanism to prevent re-introduction of information propagated
     into the Level N RA RA's RC back to the external adjacent level RA RA's RC from
     which this information has been initially received. It is thus expected that
     advertisements will include information when they have been
     derived from a source external to the RA. Note that existing
     routing protocols support mechanisms to identify advertisements of
     externally derived information and therefore an analysis of their
     applicability has to be considered on a per-protocol basis.

   In order to support operator assisted changes in the containment
   relationships of RAs, the GMPLS routing protocol is expected to
   support evolution in terms of number of hierarchical levels of RAs
   (adding and removing RAs at the top/bottom of the hierarchy), as
   well as aggregation and segmentation
   relationships of RAs. These GMPLS RAs, the routing
   capabilities are considered protocol SHALL support evolution
   in terms of lower priority as they are
   implementation specific and their method number of support should be
   evaluated on per-protocol basis e.g. OSPF vs IS-IS. In addition, 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 routing
   hierarchy are considered hierarchy, as the lowest priority requirements. Note
   also that the well as
   aggregation and segmentation of RAs. The number of hierarchical
   levels to be supported is
   implementation 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.

   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 October 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                             12
   Reachability information database
   (RDB), and the RDB is the component, which needs to support
   architecture evolution. The Design Team invites CCAMP input to
   understand the protocol-specific impacts.

   GMPLS routing currently covers all node attributes considered in
   [G.7715.1]. Assuming that the set (see Section 4.5.3) 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 set of externally endpoints
   reachable prefixes is
   built in within any routing protocol independently of its usage
   in/outside GMPLS.

   Note: some members of the Design Team noted that reachability
   information (as described in Section 4.5.3) by a node may be advertised either as a set of UNI
   Transport Resource addresses/ 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 prefixes, or a per-protocol
   basis) to determine if they are also applicable for UNI Transport
   Resource addresses. They invite CCAMP discussion on this aspect.

   From the considered list of link attributes and characteristics, the
   Local Adaptation support information is missing as TE link
   attribute. GMPLS routing does not currently consider the use set of
   dedicated TE
   associated SNPP link attribute(s) to describe the cross/inter-layer
   relationships. All other TE IDs/SNPP link attributes ID prefixes, assigned and characteristics are
   currently covered. The need for a "TE metric" per component link
   needs to be further assessed,
   selected consistently in their applicability scope. The formats of
   the sense that it can be currently
   implemented. Further consideration is here needed regarding impacts
   on TE link bundling capabilities and the increase 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
   advertisement overhead with potentially duplicated information.

   Note: protocols for use in other
   RAs (child or parent).

   As ASON does not restrict the control plane architecture choices choice
   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 A collection of the LSR requires a 1-to-1 relationship between the
   transport plane entity links and the control plane entity (Router). They
   invite CCAMP input on GMPLS capabilities nodes such as a
   sub-network or RA MUST be able to represent itself 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 wider
   network as a link advertisement.

   The inheritance property of link attributes used single logical entity with only its external links
   visible to optimize the
   component/TE link configuration process is built in within GMPLS.

W.Alanqar et al. - Expires July 2004                                12

8. topology database.

7. Acknowledgements

   The authors would like to thank Kireeti Kompella for having
   initiated the proposal of an ASON Routing Requirement Design Team.

9.

8. Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   intellectual property
   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; neither nor does it
   represent that it has made any independent effort to identify any
   such rights. Information on the
   IETF's procedures with respect to rights
   in standards-track and
   standards-related documentation RFC documents can be found in BCP-11. BCP 78 and BCP 79.

   Copies of
   claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required
   to practice implement this standard.  Please address the information to the
   IETF Executive
   Director.

10. at ietf-ipr@ietf.org.

8.1 IPR Disclosure Acknowledgement

   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.

W.Alanqar et al. - Expires October 2004                             13

9. References

10.1

9.1 Normative References

   [RFC 2026]

   [RFC2026]    S.Bradner, "The Internet Standards Process --
                Revision 3", BCP 9, RFC 2026, October 1996.

   [RFC 2119]

   [RFC2119]    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.

   [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

11. September 02.

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

   David Meyer (Cisco Systems)
   EMail: dmm@1-4-5.net

   Lyndon Ong (Ciena Corporation)
   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

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 October 2004                                14                             15

Appendix 1 - 1: ASON Terminology

   This document makes use of the following terms: following terms:

   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 domain: See Recommendation G.805. 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 (control) 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 The control plane in the form is
   subdivided into domains matching administrative domains. Within an
   administrative domain, further subdivisions of a the control domain. The entities that plane are grouped
   in a
   recursively applied. A routing control domain are components is an abstract entity
   that hides the details of the control plane. 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 [See Recommendation G.805. 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 [See Recommendation G.805. 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. Note:
   there is no routing function associated with a UNI reference point.

W.Alanqar et al. - Expires July October 2004                                15                             17

Appendix 2 - 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
   link with a single component 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 hence 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.

W.Alanqar et al. - Expires July October 2004                                16                             18

Full Copyright Statement

   "Copyright

   Copyright (C) The Internet Society (2003). All Rights Reserved. (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
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   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 October 2004                                17                             19