Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 21 Apr 2004 08:08:35 +0100

Hi ASON Routing DT, 

Please find attached a marked up copy of the draft.
All changes are typographical or nits. 

Thanks,
Adrian
 ----- Original Message -----
From: "Kireeti Kompella" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, April 15, 2004 12:46 AM
Subject: Re: FW: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt 

> Hi All, 
> 
> On Wed, 14 Apr 2004, Brungard, Deborah A, ALABS wrote: 
> 
> > The ASON Routing Reqts DT has updated the following draft based on
> > ITU Q14/15's Liaison and CCAMP mail list comments.
> >
> > We recommend this document as ready for WG Last Call. 
> 
> This commences a two-week WG Last Call on the GMPLS ASON routing
> requirements.  Last Call ends April 28th, 5pm PDT.  Please send your
> comments to the list. 
> 
> The proposed category is Informational. 
> 
> Kireeti.

---

From: [email-masked]
Date: Wed, 21 Apr 2004 18:57:20 +0200

hi adrian, much thanks for the detailed review, changes will be included 
in the updated version that will be submitted at the end of the wg last 
call process -

---

Adrian Farrel wrote:

> Subject: Re: FW: I-D 
> ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt
> 
>> Hi All,
> ------------------------------------------------------------------------
> 
> CCAMP Working Group                             Wesam Alanqar (Sprint)
> Internet Draft                                  Deborah Brungard (ATT)
> Category: Informational                    David Meyer (Cisco Systems)
>                                                     Lyndon Ong (Ciena)
> Expiration Date: October 2004          Dimitri Papadimitriou (Alcatel)
>                                              Jonathan Sadler (Tellabs)
>                                                  Stephen Shew (Nortel)
> 
> 
>                                                             April 2004
> 
> 
> 
> 
>              Requirements for Generalized MPLS (GMPLS) Routing
>              for Automatically Switched Optical Network (ASON)
> 
> 
>              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 September 2004                            1
> ## Missing page throws
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
> 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
>    [RFC2119].
> 
> 
> 3. Introduction
> 
> 
>    The GMPLS suite of protocols provides among other capabilities
>    support for controlling different switching technologies. These
>    include support for requesting TDM connections utilizing SONET/SDH
>    (see ANSI T1.105/ITU-T G.707) as well as Optical Transport Networks
>    (OTN, see ITU-T G.709). However, there are certain capabilities that
>    are needed to support the ITU-T G.8080 control plane architecture
>    for Automatically Switched Optical Network (ASON). Therefore, it is
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                              2
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
>    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).
> 
>>   supported is NOT specified (outside the scope of this document).
> 
>    - Within an ASON RA and for each level of the routing hierarchy,
>      multiple routing paradigms (hierarchical, step- by-step, source-
>      based), centralized or distributed path computation, and multiple
>      different routing protocols MAY be supported. The architecture
>      does NOT assume a one-to-one correspondence of a routing protocol
>      and a RA level and allows the routing protocol(s) used within
>      different RAs (including child and parent RAs) to be different.
>      The realization of the routing paradigm(s) to support the
>      hierarchical levels of RAs is NOT specified.
>    - The routing adjacency topology (i.e. the associated Protocol
>      Controller (PC) connectivity) and transport topology is NOT
>      assumed to be congruent.
>    - The requirements support architectural evolution, e.g. a change in
>      the number of RA levels, as well as aggregation and segmentation
>      of RAs.
> 
> 
>    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.
> 
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                              3
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
> 4. ASON Routing Architecture and Requirements
> 
> ## trivial: you have "a RA" also "an RP"
> 
>    The fundamental architectural concept is the RA and it's related
>    functional components (see Appendix 2 on terminology). The routing
>    services offered by a RA are provided by a Routing Performer (RP).
>    An RP is responsible for a single RA, and it MAY be functionally
>    realized using distributed Routing Controllers (RC). The RC, itself,
>    MAY be implemented as a cluster of distributed entities (ASON refers
>    to the cluster as a Routing Control Domain (RCD)). The RC components
>    for a RA receive routing topology information from their associated
>    Link Resource Manager(s) (LRMs) and store this information in the
>    Routing Information Database (RDB). The RDB is replicated at each RC
> <  bounded to the same Routing Area (RA), and MAY contain information
> 
>> 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 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 recover from the failure condition MUST NOT
> 
>> and the subsequent recovery from the failure condition MUST NOT
> 
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                              4
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
>    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) 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
> <  bounded to the same parent RA (see Section 4.2). A RA identifier (RA
> 
>> 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 bounded to the same RA, an
> 
>> 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
> 
>> 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
> 
>> 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
> 
> 
> <  Routing information can be exchanged between RCs bounded to adjacent
> 
>> 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
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                              5
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
>    exchanged between a RC, its parent, and its child RCs, it SHOULD
>    include reachability and MAY include (upon policy decision) node and
> <  link topology. Only the RCs of the parent RA communicate, RCs of one
> <  childÆs RA never communicate with the RCs of other child RAs. There
> 
>> 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 bounded to the same RA MAY transform (filter,
> 
>> 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; 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 exchange are expected:
> 
>>    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
>         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 to be re-introduced into the Level N+1 RA's
> <       RC, and
> 
>>      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 to be re-introduced into the Level N-1 RA's
> 
>>      the Level N RA's RC from being re-introduced into the Level N-1 RA's
> 
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                              6
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
>         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.
> 
> 
>       - 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 parent and its child within the hierarchical
> 
>> relationship to its parent and its children within the hierarchical
> 
>    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
> 
>> PC adjacencies to other RCs bounded to the same parent RA. The
> 
> <  PC adjacencies to other RCs bound to the same parent RA. The
> ## Do you really mean PC or RC?
>    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
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                              7
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
> <  as aggregation and segmentation of RAs. RA IDs uniqueness within an
> 
>> 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
> ## Surely this is MUST?
>    disrupt calls in progress, though calls being set up may fail to
>    complete, and the call setup service may be unavailable during
>    reconfiguration actions.
> 
> 
> 4.5 Routing Attributes
> 
> 
>    Routing for transport networks is performed on a per layer basis,
>    where the routing paradigms MAY differ among layers and within a
> <  layer. Not all equipment support the same set of transport layers or
> 
>> 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).
> 
> 
>    (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, SNP, for the control plane representation of a
> 
>> 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
> <  SNPP. The routing function understands topology in terms of SNPP
> 
>> 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.
> 
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                              8
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
> 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
> 
>> - RA ID of the RA to which the advertisement is bound
> 
>    - 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 level of support required in
> 
>> following tables, Capability refers to the level of support required in
> 
>    the realization of a link state routing protocol, whereas Usage
> <  refers to degree of operational and implementation flexibility.
> 
>> refers to the 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
> 
> 
>    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 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
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                              9
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
>        Remote SNPP link ID              REQUIRED        REQUIRED
>        Layer Specific Characteristics   see Table 3
> 
> 
>                 Table 2. Link Attributes
> 
> 
>    The SNPP link ID name MUST be sufficient to uniquely identify the
> ## Why do you say "SNPP link ID name"? This is not defined.
> ## Do you mean "SNPP link ID"?
>    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 TCP, CP, or can be flexibly configured as a TCP.
> ## Please expand TCP and CP in their first uses
> 
> 
>    - 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
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                             10
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
>         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
> 
>> 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. 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
> 
>> - 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
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                             11
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
>      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
>      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
> 
>> - 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
> <  - when multiple RCs bound to a RA transform (filter, summarize,
> <    etc.) and then forward information to RC(s) at different levels
> <    that the resulting information at the receiving level is self-
> <    consistent
> 
>> - 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
> 
>> - 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. Example: support
> 
>> 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.
> 
> 
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                             12
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
>    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
> 
> 
>    The authors would like to thank Kireeti Kompella for having
>    initiated the proposal of an ASON Routing Requirement Design Team.
> ## Perhaps it would be good to acknowledge any other contributors you had.
> ## In particular SG14/15 for their careful review and input.
> 
> 8. Intellectual Property Considerations
> 
> 
>    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 [email-masked].
> 
> 
> 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
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
> 9. References
> 
> 
> 9.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.
> 
> 
>    [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, September 02.
> 
> ## Would it be OK to make the external references informative?
> 
> 10. Author's Addresses
> 
> 
>    Wesam Alanqar (Sprint)
>    EMail: [email-masked]
> 
> 
>    Deborah Brungard (AT&T)
>    Rm. D1-3C22 - 200 S. Laurel Ave.
>    Middletown, NJ 07748, USA
>    Phone: +1 732 4201573
>    EMail: [email-masked]
> 
> 
>    David Meyer (Cisco Systems)
>    EMail: [email-masked]
> 
> 
>    Lyndon Ong (Ciena Corporation)
>    5965 Silver Creek Valley Rd,
>    San Jose, CA 95128, USA
>    Phone: +1 408 8347894
>    EMail: [email-masked]
> 
> 
>    Dimitri Papadimitriou (Alcatel)
>    Francis Wellensplein 1,
>    B-2018 Antwerpen, Belgium
>    Phone: +32 3 2408491
>    EMail: [email-masked]
> 
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                             14
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
>    Jonathan Sadler
>    1415 W. Diehl Rd
>    Naperville, IL 60563
>    EMail: [email-masked]
> 
> 
>    Stephen Shew (Nortel Networks)
>    PO Box 3511 Station C
>    Ottawa, Ontario, CANADA K1Y 4H7
>    Phone: +1 613 7632462
>    EMail: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> W.Alanqar et al. - Expires October 2004                             15
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
> Appendix 1: ASON Terminology
> 
> 
>    This document makes use of the 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 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. 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
>    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
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
>    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.
> 
> 
> ## Add SNPP
> ## Add TCP
> 
>    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 October 2004                             17
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 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 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 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 October 2004                             18
> draft-ietf-ccamp-gmpls-ason-routing-reqts-03.txt            April 2004
> 
> 
> 
> Full Copyright Statement
> 
> ## Require new copyright boilerplate
> 
> 
>    Copyright (C) The Internet Society (2004). This document is subject
>    to the rights, licenses and restrictions contained in BCP 78 and
>    except as set forth therein, the authors retain all their rights.
> 
> 
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implementation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph
>    are included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    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 October 2004                             19

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491