[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-dimitri-ccamp-gmpls-ason-routing-eval) 00 01 02 03 RFC 4652

CCAMP Working Group                                Chris Hopps (Cisco)
Internet Draft                                      Lyndon Ong (Ciena)
Category: Informational                Dimitri Papadimitriou (Alcatel)
                                             Jonathan Sadler (Tellabs)
Expiration Date: January 2006                    Stephen Shew (Nortel)
                                                     Dave Ward (Cisco)


                                                             July 2005


                 Evaluation of existing Routing Protocols
                     against ASON Routing Requirements

              draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2005). All Rights Reserved.

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





C.Hopps et al. - Expires January 2006                                1
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


   This document provides an evaluation of the IETF Routing Protocols
   against the routing requirements for an Automatically Switched
   Optical Network (ASON) as defined by ITU-T.

1. Contributors

   This document is the result of the CCAMP Working Group ASON Routing
   Solution design team joint effort.

   Dimitri Papadimitriou (Alcatel, Team Leader and Editor)
      EMail: dimitri.papadimitriou@alcatel.be
   Chris Hopps (Cisco)
      EMail: chopps@rawdofmt.org
   Lyndon Ong (Ciena Corporation)
      EMail: lyong@ciena.com
   Jonathan Sadler (Tellabs)
      EMail: jonathan.sadler@tellabs.com
   Stephen Shew (Nortel Networks)
      EMail: sdshew@nortelnetworks.com
   Dave Ward (Cisco)
      EMail: dward@cisco.com

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

   There are certain capabilities that are needed to support the ITU-T
   Automatically Switched Optical Network (ASON) control plane
   architecture as defined in [G.8080].

   [ASON-RR] details the routing requirements for the GMPLS routing
   suite of protocols to support the capabilities and functionality of
   ASON control planes identified in [G.7715] and in [G.7715.1]. 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.

   However, [ASON-RR] does not address GMPLS routing protocol
   applicability or capabilities. This document evaluates the IETF
   Routing Protocols against the requirements identified in [ASON-RR].
   The result of this evaluation is detailed in Section 5. Close
   examination of applicability scenarios and the result of the
   evaluation of these scenarios are provided in Section 6.

   ASON (Routing) terminology sections are provided in Appendix 1 and 2.


C.Hopps et al. - Expires January 2006                                2
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005



4. Requirements - Overview

   The following functionality is expected from GMPLS routing protocol
   to instantiate the ASON hierarchical routing architecture realization
   (see [G.7715] and [G.7715.1]):
   - Routing Areas (RAs) shall be uniquely identifiable within a
     carrier's network, each having a unique RA Identifier (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
     Routing DataBases (RDB) become synchronized after a period of
     time.

   To support dissemination of hierarchical routing information, the
   routing protocol must deliver:
   - Processing of routing information exchanged between adjacent
     levels of the hierarchy (i.e. Level N+1 and N) including
     reachability and upon policy decision summarized topology
     information.
   - Self-consistent information at the receiving level resulting from
     any transformation (filter, summarize, etc.) and forwarding of
     information from one Routing Controller (RC) to RC(s) at different
     levels when multiple RCs bound to a single RA.
   - A mechanism to prevent re-introduction of information propagated
     into the Level N RA's RC back to the adjacent level RA's RC from
     which this information has been initially received.

   Note: the number of hierarchical levels to be supported is routing
   protocol specific and reflects a containment relationship.

   Reachability information may be advertised either as a set of UNI
   Transport Resource address prefixes, or a set of associated
   Subnetwork Point Pool (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).



C.Hopps et al. - Expires January 2006                                3
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


   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.

5. Evaluation

   This section evaluates support of existing IETF routing protocols
   with respect to the requirements summarized from [ASON-RR] in Section
   4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The
   latter in not addressed in the current version of this document.

5.1 Terminology and Identification

   - Pi is a physical node (bearer/data/transport plane) node

   - Li is a logical control plane entity that is associated to a
     single data plane (abstract) node. The Li is identified by the
     TE Router_ID. The latter is a control plane identifier defined as
     . RFC 3630: Router_Address (top level) TLV of the Type 1 TE LSA
     . RFC 3784: Traffic Engineering Router ID TLV (Type 134)

     Note: this document does not define what the TE Router ID is. This
     document simply states the use of the TE Router ID to identify
     the Li. Other documents (the referenced RFC 3630 and RFC
     3784) provide the definitions.

   - Ri is a logical control plane entity that is associated to a
     control plane "router". The latter is the source for topology
     information that it generates and shares with other control plane
     "routers". The Ri is identified by the (advertising) Router_ID
     . RFC 2328: Router ID (32-bit)
     . RFC 1195: IS-IS System ID (48-bit)

     The Router_ID, represented by Ri and that corresponds to the RC_ID
     [ASON-REQ], does not enter into the identification of the logical
     entities representing the data plane resources such as links. The
     Routing DataBase (RDB) is associated to the Ri. Note that, in the
     ASON context, arrangement considering multiple Ri's announcing
     routing information related to a single Li is under evaluation.

   Aside from the Li/Pi mappings, these identifiers are not assumed to
   be in a particular entity relationship except that the Ri may have
   multiple Li in its scope. The relationship between Ri and Li is
   simple at any moment in time: an Li may be advertised by only one Ri
   at any time. However, an Ri may advertise a set of one or more Li's.
   Thus, the routing protocol MUST be able to advertise multiple TE
   Router IDs.




C.Hopps et al. - Expires January 2006                                4
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


   Note: Si is a control plane signaling function associated with one
   or more Li. This document does not assume any specific constraint on
   the relationship between Si and Li. This document does not discuss
   issues of control plane accessibility for signaling function, and
   makes no assumptions about how control plane accessibility to the Si
   is achieved.

5.2 RA Identification

   G.7715.1 notes some necessary characteristics for RA identifiers,
   e.g., that they may provide scope for the Ri, and that they must be
   provisioned to be unique within an administrative domain. The RA ID
   format itself is allowed to be derived from any global address space.
   Provisioning of RA IDs for uniqueness is outside the scope of this
   document.

   Under these conditions, GMPLS link state routing protocols provide
   the capability for RA Identification.

5.3 Routing Information Exchange

   We focus on routing information exchange between Ri entities
   (through routing adjacencies) within single hierarchical level.
   Routing information mapping between levels may require specific
   guidelines.

   The control plane does not transport Pi information as these are
   data plane addresses for which the Li/Pi mapping is kept (link)
   local - see for instance the transport LMP document [LMP-T] where
   such exchange is described. Example: the transport plane identifier
   is the Pi (the identifier assigned to the physical element) that
   could be for instance "666B.F999.AF10.222C", whereas the control
   plane identifier is the Li (the identifier assigned by the control
   plane), which could be for instance "1.1.1.1".

   The control plane exchanges the control plane identifier information
   but not the transport plane identifier information (i.e. not
   "666B.F999.AF10.222C" but only "1.1.1.1"). The mapping Li/Pi is kept
   local. So, when the Si receives a control plane message requesting
   the use of "1.1.1.1", Si knows locally that this information refers
   to the data plane entity identified by the transport plane
   identifier "666B.F999.AF10.222C".

   The control plane carries:
   1) its view of the data plane link end-points and other link
   connection end-points
   2) the identifiers scoped by the Li's i.e. referred to as an
   associated IPv4/IPv6 addressing space
   3) when using OSPF or ISIS as the IGP in support of traffic
   engineering, RFC 3477 RECOMMENDS that the Li value (referred to the
   "LSR Router ID") to be set to the TE Router ID value.



C.Hopps et al. - Expires January 2006                                5
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


5.3.1 Link Attributes

   From the list of link attributes and characteristics (detailed in
   [ASON-RR], the Local Adaptation support information is missing as TE
   link attribute. GMPLS routing does not currently consider the use of
   dedicated TE link attribute(s) to describe the cross/inter-layer
   relationships. All other TE link attributes and characteristics are
   currently covered (see Table 1.)

   However, the representation of bandwidth requires further analysis
   i.e. GMPLS Routing defines an Interface Switching Capability
   Descriptor (ISCD) that delivers information about the (maximum/
   minimum) bandwidth per priority an LSP can make use of. In the ASON
   context, other representations are possible, e.g., in terms of a set
   of tuples <signal_type; number of unallocated timeslots>. The latter
   also may require definition of additional signal types (from those
   defined in [RFC 3496]) to represent contiguous concatenation i.e.
   STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.

   The method proposed in [GMPLS-RTG] is the most straightforward
   without requiring any bandwidth accounting change from an LSR
   perspective. However, it introduces some lost of information. This
   lost of information affects the number of signals that can be used
   but not the range they cover. On the other hand, if additional
   technology specific information (such as capabilities) are
   advertised a finer grained resource countdown and accounting can be
   performed allowing for network wide resource allocation in Sonet/SDH
   environments.

   Link Characteristics     GMPLS OSPF
   -----------------------  ----------
   Local SNPP link ID       Link local part of the TE link identifier
                            sub-TLV [GMPLS-OSPF]
   Remote SNPP link ID      Link remote part of the TE link identifier
                            sub-TLV [GMPLS-OSPF]
   Signal Type              Technology specific part of the Interface
                            Switching Capability Descriptor sub-TLV
                            [GMPLS-OSPF]
   Link Weight              TE metric sub-TLV [RFC3630]
   Resource Class           Administrative Group sub-TLV [RFC3630]
   Local Connection Types   Switching Capability field part of the
                            Interface Switching Capability Descriptor
                            sub-TLV [GMPLS-OSPF]
   Link Capacity            Unreserved bandwidth sub-TLV [RFC3630]
                            Max LSP Bandwidth part of the Interface
                            Switching Capability Descriptor sub-TLV
                            [GMPLS-OSPF]
   Link Availability        Link Protection sub-TLV [GMPLS-OSPF]
   Diversity Support        SRLG sub-TLV [GMPLS-OSPF]
   Local Adaptation support see above




C.Hopps et al. - Expires January 2006                                6
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


   Link Characteristics     GMPLS IS-IS
   -----------------------  -----------
   Local SNPP link ID       Link local part of the TE link identifier
                            sub-TLV [GMPLS-ISIS]
   Remote SNPP link ID      Link remote part of the TE link identifier
                            sub-TLV [GMPLS-ISIS]
   Signal Type              Technology specific part of the Interface
                            Switching Capability Descriptor sub-TLV
                            [GMPLS-ISIS]
   Link Weight              TE Default metric [RFC3784]
   Resource Class           Administrative Group sub-TLV [RFC3784]
   Local Connection Types   Switching Capability field part of the
                            Interface Switching Capability Descriptor
                            sub-TLV [GMPLS-ISIS]
   Link Capacity            Unreserved bandwidth sub-TLV [RFC3784]
                            Max LSP Bandwidth part of the Interface
                            Switching Capability Descriptor sub-TLV
                            [GMPLS-ISIS]
   Link Availability        Link Protection sub-TLV [GMPLS-ISIS]
   Diversity Support        SRLG sub-TLV [GMPLS-ISIS]
   Local Adaptation support see above

      Table 1. TE link Attribute in GMPLS OSPF-TE and GMPLS IS-IS-TE,
                               respectively

   Note: Link Attributes represent layer resource capabilities and
   their utilization.

5.3.2 Node Attributes

   Nodes attributes include the "Logical Node ID" (as detailed in
   Section 5.1) and the reachability information as described in
   Section 5.3.3.

5.3.3 Reachability Information

   Advertisement of reachability can be achieved using the techniques
   described in [OSPF-NODE] where the set of local addresses are
   carried in an OSPF TE LSA node attribute TLV (a specific sub-TLV is
   defined per address family, e.g., IPv4 and IPv6). However, [OSPF-
   NODE] restricts to advertisement of Host addresses and not prefixes,
   and therefore requires enhancement (see below).

   A similar mechanism does not exist for IS-IS as the Extended IP
   Reachability TLV [RFC3784] focuses on IP reachable end-points
   (terminating points), as its name indicates.

   In order to advertise blocks of reachable address prefixes a
   summarization mechanism is additionally required. This mechanism may
   take the form of an prefix length (that indicates the number of
   significant bits in the prefix) or a network mask.



C.Hopps et al. - Expires January 2006                                7
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


5.4 Routing Information Abstraction

   G.7715.1 describes both static and dynamic methods for abstraction of
   routing information for advertisement at a different level of the
   routing hierarchy. However, the information that is advertised
   continues to be in the form of link and node advertisements
   consistent with the link state routing protocol used at that level,
   hence no specific capabilities are added to the routing protocol
   beyond the ability to locally identify when routing information
   originates outside of a particular RA.

   The methods used for abstraction of routing information are outside
   the scope of GMPLS routing protocols.

5.5 Dissemination of routing information in support of multiple
hierarchical levels of RAs

   G.7715.1 does not define specific mechanisms to support multiple
   hierarchical levels of RAs, beyond the ability to support abstraction
   as discussed above. However, if RCs bound to adjacent levels of the
   RA hierarchy were allowed to redistribute routing information in
   both directions between adjacent levels of the hierarchy without any
   additional mechanisms, they would not be able to determine looping
   of routing information.

   To prevent this looping of routing information between levels, IS-IS
   [RFC1195] allows only advertising routing information upward in the
   level hierarchy, and disallow the advertising of routing information
   downward in the hierarchy. [RFC2966] defines the up/down bit to
   allow advertising downward in the hierarchy the "IP Internal
   Reachability Information" TLV (Type 128) and "IP External
   Reachability Information" TLV (Type 130). [RFC3784] extends its
   applicability for the "Extended IP Reachability" TLV (Type 135).
   Using this mechanism, the up/down bit is set to 0 when routing
   information is first injected into IS-IS. If routing information is
   advertised from a higher level to a lower level, the up/down bit is
   set to 1, indicating that it has traveled down the hierarchy.
   Routing information that has the up/down bit set to 1 may only be
   advertised down the hierarchy, i.e. to lower levels. This mechanism
   applies independently of the number of levels. However, this
   mechanism does not apply to the "Extended IS Reachability" TLV (Type
   22) used to propagate the summarized topology (see Section 5.3),
   traffic engineering information as listed in Table 1, as well as
   reachability information (see Section 5.3.3).

   OSPFv2 prevents that inter-area routes, which are learned from area
   0 are not passed back to area 0. However, GMPLS makes use of Type 10
   (area-local scope) LSA to propagate TE information [RFC3630], [GMPLS-
   RTG]. Type 10 Opaque LSAs are not flooded beyond the borders of
   their associated area. It is therefore necessary to have a means by
   which Type 10 Opaque LSA may carry the information that particular
   routing information has been learned from a higher level RC when


C.Hopps et al. - Expires January 2006                                8
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


   propagated to a lower level RC. Any downward RC from this level,
   which receives an LSA with this information would omit the
   information in this LSA and thus not re-introduce this information
   back into an higher level RC.

5.6 Routing Protocol Convergence

   Link state protocols have been designed to detect topological
   changes (such as interface failures, link attributes modification).
   Convergence period is short and involves a minimum of routing
   information exchange.

   Therefore, existing routing protocol convergence mechanisms are
   sufficient for ASON applications.

5.7 Routing Information Scoping

   The routing protocol MUST support a single Ri advertising on behalf
   of more than one Li. Since each Li is identified by a unique
   TE Router ID, the routing protocol MUST be able to advertise
   multiple TE Router IDs.

   The Link sub-TLV currently part of the top level Link TLV associates
   the link to the Router_ID. However, having the Ri advertising on
   behalf multiple Li's creates the following issue as there is no more
   a 1:1 relationship between the Router_ID and the TE Router_ID but a
   1:N relationship is possible (see Section 5.1). As the link local
   and link remote (unnumbered) ID association may be not unique per
   abstract node (per Li unicity), the TE link advertisement needs to
   additionally indicate the remote Lj value such as to unambiguously
   retrieve the [Li;Lj] relationship(s). In brief, as unnumbered links
   have their ID defined on per Li bases, the remote Lj needs to be
   identified to scope the link remote ID to the local Li. Therefore,
   the routing protocol MUST be able to disambiguate the advertised TE
   links so that they can be associated with the correct TE Router ID.

   Moreover, when the Ri advertises on behalf multiple Li's, the
   routing protocol MUST be able to disambiguate the advertised
   reachability information (see Section 5.3.3) so that it can be
   associated with the correct TE Router ID.

6. Evaluation Scenarios

   The evaluation scenarios are the following: referred to as
   respectively case 1), 2), 3) and 4). Additional base scenarios
   (being not combinations or decomposition of entities) may further
   complete this set in a future revision of this document.

   In the below Figure 1:
   - R3 represents an LSR with all components collocated.
   - R2 shows how the "router" component may be disjoint from the node



C.Hopps et al. - Expires January 2006                                9
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


   - R1 shows how a single "router" may manage multiple nodes

                -------------------     -------
               |R1                 |   |R2     |
               |                   |   |       |    ------
               |  L1    L2    L3   |   |   L4  |   |R3    |
               |   :     :     :   |   |   :   |   |      |
               |   :     :     :   |   |   :   |   |  L5  |
   Control      ---+-----+-----+---     ---+---    |   :  |
   Plane           :     :     :           :       |   :  |
   ----------------+-----+-----+-----------+-------+---+--+-
   Data            :     :     :           :       |   :  |
   Plane          --     :    --          --       |  --  |
             ----|P1|--------|P3|--------|P4|------+-|P5|-+-
                  -- \   :  / --          --       |  --  |
                      \ -- /                       |      |
                       |P2|                         ------
                        --

   Case 1) as represented refers either to direct links between edges
   or "logical links" as per below figure (or any combination of them)

                   ------                        ------
                  |      |                      |      |
                  |  L1  |                      |  L2  |
                  |  :   |                      |  :   |
                  |  : R1|                      |  : R2|
   Control Plane   --+---                        --+---
   Elements          :                             :
   ------------------+-----------------------------+------------------
   Data Plane        :                             :
   Elements          :                             :
                 ----+-----------------------------+-----
                |    :                             :     |
                |   ---            ---            ---    |
                |  |   |----------| P |----------|   |   |
             ---+--|   |           ---           |   |---+---
                |  |   |                         |   |   |
                |  | P1|-------------------------| P2|   |
                |   ---                           ---    |
                 ----------------------------------------

   Another case (referred to as Case 4) is constituted by the Abstract
   Node as represented in the below figure. There is no internal
   structure associated (externally) to the abstract node.

                       --------------
                      |R4            |
                      |              |
                      |      L6      |
                      |       :      |
                      |    ......    |


C.Hopps et al. - Expires January 2006                               10
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


                       ---:------:---
   Control Plane          :      :
                   +------+------+------+
   Data Plane             :      :
                       ---:------:---
                      |P8 :      :   |
                      |  --      --  |
                    --+-|P |----|P |-+--
                      |  --      --  |
                       --------------

   Note: the "signaling function" i.e. the control plane entity that
   processes the signaling messages (referred to as Si) is not
   represented in these Figures. More than one Si can be associated to
   one Ri (N:1 relationship, N >= 1) and make use of the path
   computation function associated to the Ri.

7. Acknowledgements

   The authors would like to thank Adrian Farrel for having initiated
   the proposal of an ASON Routing Solution Design Team and the ITU-T
   SG15/Q14 for their careful review and input.

8. References

8.1 Normative References

   [GMPLS-RTG]  Kompella, K. (Editor) et al., "Routing Extensions in
                Support of Generalized MPLS," Internet Draft (work in
                progress), draft-ietf-ccamp-gmpls-routing-09.txt,
                October 2003.

   [LMP-T]      D.Fedyk et al., "A Transport Network View of LMP,"
                Internet Draft (work in progress), draft-ietf-ccamp-
                transport-lmp-02, May 2005.

   [OSPF-NODE]  R.Aggarwal, and K.Kompella, "Advertising a Router's
                Local Addresses in OSPF TE Extensions," Internet Draft,
                (work in progress), draft-ietf-ospf-te-node-addr-
                02.txt, March 2005.

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

   [RFC2328]    J.Moy, "OSPF Version 2", RFC 2328, April 1998.

   [RFC2119]    S.Bradner, "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3477]    K.Kompella et al. "Signalling Unnumbered Links in
                Resource ReSerVation Protocol - Traffic Engineering
                (RSVP-TE)", RFC 3477, January 2003.


C.Hopps et al. - Expires January 2006                               11
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005



   [RFC3630]    D.Katz et al. "Traffic Engineering (TE) Extensions to
                OSPF Version 2", RFC 3630, September 2003.

   [RFC3667]    S.Bradner, "IETF Rights in Contributions", BCP 78,
                RFC 3667, February 2004.

   [RFC3668]    S.Bradner, Ed., "Intellectual Property Rights in IETF
                Technology", BCP 79, RFC 3668, February 2004.

   [RFC3784]    H.Smit and T.Li, "Intermediate System to Intermediate
                System (IS-IS) Extensions for Traffic Engineering (TE),"
                RFC 3784, June 2004.

   [RFC3946]    E.Mannie, and D.Papadimitriou, (Editors) et al.,
                "Generalized Multi-Protocol Label Switching Extensions
                for SONET and SDH Control," RFC 3946, October 2004.

8.2 Informative References

   [ASON-RR]    W.Alanqar et al. "Requirements for Generalized MPLS
                (GMPLS) Routing for Automatically Switched Optical
                Network (ASON)," Work in progress, draft-ietf-ccamp-
                gmpls-ason-routing-reqts-05.txt, October 2004.

   For information on the availability of ITU Documents, please see
   http://www.itu.int

   [G.7715]     ITU-T Rec. G.7715/Y.1306, "Architecture and
                Requirements for the Automatically Switched Optical
                Network (ASON)," June 2002.

   [G.7715.1]   ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing
                Architecture and Requirements for Link State Protocols,"
                November 2003.

   [G.8080]     ITU-T Rec. G.8080/Y.1304, "Architecture for the
                Automatically Switched Optical Network (ASON),"
                November 2001 (and Revision, January 2003).

9. Author's Addresses

   Lyndon Ong (Ciena Corporation)
   PO Box 308
   Cupertino, CA 95015 , USA
   Phone: +1 408 705 2978
   EMail: lyong@ciena.com

   Dimitri Papadimitriou (Alcatel)
   Francis Wellensplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 2408491


C.Hopps et al. - Expires January 2006                               12
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


   EMail: dimitri.papadimitriou@alcatel.be

   Jonathan Sadler
   1415 W. Diehl Rd
   Naperville, IL 60563
   EMail: jonathan.sadler@tellabs.com

   Stephen Shew (Nortel Networks)
   PO Box 3511 Station C
   Ottawa, Ontario, CANADA K1Y 4H7
   Phone: +1 613 7632462
   EMail: sdshew@nortelnetworks.com

   Dave Ward (Cisco Systems)
   170 W. Tasman Dr.
   San Jose, CA 95134 USA
   Phone: +1-408-526-4000
   EMail: dward@cisco.com




































C.Hopps et al. - Expires January 2006                               13
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


Appendix 1: ASON Terminology

   This document makes use of the following terms:

   Administrative domain: (see Recommendation G.805) for the purposes of
   [G7715.1] an administrative domain represents the extent of resources
   which belong to a single player such as a network operator, a service
   provider, or an end-user. Administrative domains of different players
   do not overlap amongst themselves.

   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.

   Subnetwork Point (SNP): The SNP is a control plane abstraction that
   represents an actual or potential transport plane resource. SNPs (in


C.Hopps et al. - Expires January 2006                               14
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


   different subnetwork partitions) may represent the same transport
   resource. A one-to-one correspondence should not be assumed.

   Subnetwork Point Pool (SNPP): A set of SNPs that are grouped together
   for the purposes of routing.

   Termination Connection Point (TCP): A TCP represents the output of a
   Trail Termination function or the input to a Trail Termination Sink
   function.

   Transport plane: provides bi-directional or unidirectional transfer
   of user information, from one location to another. It can also
   provide transfer of some control and network management information.
   The Transport Plane is layered; it is equivalent to the Transport
   Network defined in G.805 Recommendation.

   User Network Interface (UNI): interfaces are located between protocol
   controllers between a user and a control domain. Note: there is no
   routing function associated with a UNI reference point.



































C.Hopps et al. - Expires January 2006                               15
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


Appendix 2: ASON Routing Terminology

   This document makes use of the following terms:

   Routing Area (RA): a RA represents a partition of the data plane and
   its identifier is used within the control plane as the representation
   of this partition. Per [G.8080] a RA is defined by a set of sub-
   networks, the links that interconnect them, and the interfaces
   representing the ends of the links exiting that RA. A RA may contain
   smaller RAs inter-connected by links. The limit of subdivision
   results in a RA that contains two sub-networks interconnected by a
   single link.

   Routing Database (RDB): repository for the local topology, network
   topology, reachability, and other routing information that is updated
   as part of the routing information exchange and may additionally
   contain information that is configured. The RDB may contain routing
   information for more than one Routing Area (RA).

   Routing Components: ASON routing architecture functions. These
   functions can be classified as protocol independent (Link Resource
   Manager or LRM, Routing Controller or RC) and protocol specific
   (Protocol Controller or PC).

   Routing Controller (RC): handles (abstract) information needed for
   routing and the routing information exchange with peering RCs by
   operating on the RDB. The RC has access to a view of the RDB. The RC
   is protocol independent.

   Note: Since the RDB may contain routing information pertaining to
   multiple RAs (and possibly to multiple layer networks), the RCs
   accessing the RDB may share the routing information.

   Link Resource Manager (LRM): supplies all the relevant component and
   TE link information to the RC. It informs the RC about any state
   changes of the link resources it controls.

   Protocol Controller (PC): handles protocol specific message exchanges
   according to the reference point over which the information is
   exchanged (e.g. E-NNI, I-NNI), and internal exchanges with the RC.
   The PC function is protocol dependent.













C.Hopps et al. - Expires January 2006                               16
draft-ietf-ccamp-gmpls-ason-routing-eval-01.txt              July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard. Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.










C.Hopps et al. - Expires January 2006                               17


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/