Internet DRAFT - draft-ietf-ccamp-gmpls-ason-routing-eval

draft-ietf-ccamp-gmpls-ason-routing-eval





CCAMP Working Group                                Chris Hopps (Cisco) 
Internet Draft                                      Lyndon Ong (Ciena) 
Category: Informational                Dimitri Papadimitriou (Alcatel) 
                                             Jonathan Sadler (Tellabs) 
Expiration Date: December 2006                   Stephen Shew (Nortel) 
                                                     Dave Ward (Cisco) 
                                                                       
                                                              May 2006 
    
    
                 Evaluation of existing Routing Protocols 
                     against ASON routing requirements 
                                      
              draft-ietf-ccamp-gmpls-ason-routing-eval-03.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. 
    
     
    
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 provides an evaluation of the IETF Routing Protocols 
   against the routing requirements for an Automatically Switched 
   Optical Network (ASON) as defined by ITU-T. 
    
     
 
 
C.Hopps et al. - Expires December 2006                               1 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
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]. 
    
   The reader is expected to be familiar with the terminology introduced 
   in [RFC4258].  
    
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].  
    
   [RFC4258] 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, [RFC4258] does not address GMPLS routing protocol 
   applicability or capabilities. This document evaluates the IETF 
   Routing Protocols against the requirements identified in [RFC4258]. 
   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-03.txt               May 2006 
 
 
4. Requirements - Overview 
    
   The following functionality is expected from GMPLS routing protocols 
   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 are 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-03.txt               May 2006 
 
 
   As ASON does not restrict the control plane architecture choice, 
   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 [RFC4258] in Section 
   4. Candidate routing protocols are IGP (OSPF and IS-IS) and BGP. The 
   latter is not addressed in the current version of this document. BGP 
   is not considered a candidate protocol mainly because of 
   - non-support of TE information exchange: each BGP router advertises  
     only its path to each destination in its vector for loop avoidance,  
     with no costs or hop counts; each BGP router knows little about  
     network topology 
   - BGP can only advertise routes that are eligible for use (local RIB)  
     or routing loops can occur; there is one best route per prefix, and  
     that is the route that is advertised. 
   - BGP is not widely deployed in optical equipment and networks 
    
5.1 Terminology and Identification 
    
   - Pi is a physical (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  
     follows: 
     . [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 Li. [RFC 3630] and [RFC3784] 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  
     [RFC4258], 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, an arrangement consisting of multiple Ri's  
     announcing routing information related to a single Li is under  
     evaluation. 
 
 
C.Hopps et al. - Expires January 2006                                4 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
    
   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 (see Section 5.7). 
 
   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 the 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 without further modification.  
    
5.3 Routing Information Exchange 
    
   In this section, the focus is on routing information exchange Ri 
   entities (through routing adjacencies) within a single hierarchical 
   level. Routing information mapping between levels require specific 
   processing (see Section 5.5).  
    
   The control plane does not transport Pi identifiers as these are 
   data plane addresses for which the Li/Pi mapping is kept (link) 
   local - see for instance the transport LMP document [RFC4394] where 
   such an 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 "192.0.2.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 "192.0.2.1"). The mapping Li/Pi is 
   kept local. So, when the Si receives a control plane message 
   requesting the use of "192.0.2.1", Si knows locally that this 
   information refers to the data plane entity identified by the 
   transport plane identifier "666B.F999.AF10.222C".  
    
 
 
C.Hopps et al. - Expires January 2006                                5 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
   Note also that the Li and Pi addressing spaces may be identical. 
    
    
   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; note that these identifiers 
   may either be bundled TE link addresses or component link addresses 
   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.  
    
   Therefore, OSPF and IS-IS carry sufficient node identification 
   information without further modification. 
    
5.3.1 Link Attributes 
    
   [RFC4258] provides a list of link attributes and characteristics 
   that need to be advertised by a routing protocol. All TE link 
   attributes and characteristics are currently handled by OSPF and IS-
   IS (see Table 1) with the exception of Local Adaptation support. 
   Indeed, GMPLS routing does not currently consider the use of 
   dedicated TE link attribute(s) to describe the cross/inter-layer 
   relationships. 
    
   In addition, the representation of bandwidth requires further 
   consideration. GMPLS Routing defines an Interface Switching 
   Capability Descriptor (ISCD) that delivers information about the 
   (maximum/ minimum) bandwidth per priority of which an LSP can make 
   use. This information is usually used in combination with the 
   Unreserved Bandwidth sub-TLV that provides the amount of bandwidth 
   not yet reserved on a TE link.  
    
   In the ASON context, other bandwidth accounting representations are 
   possible, e.g., in terms of a set of tuples <signal_type; number of 
   unallocated timeslots>. The latter representation may also require 
   definition of additional signal types (from those defined in 
   [RFC3946]) to represent support of contiguously concatenated signals 
   i.e. STS-(3xN)c SPE / VC-4-Nc, N = 4, 16, 64, 256.  
    
   However, the method proposed in [RFC4202] is the most 
   straightforward without requiring any bandwidth accounting change 
   from an LSR perspective (in particular, when the ISCD sub-TLV 
   information is combined with the information provided by the 
   Unreserved Bandwidth sub-TLV). 
 
   Link Characteristics     GMPLS OSPF  
   -----------------------  ---------- 
   Local SNPP link ID       Link local part of the TE link identifier 
                            sub-TLV [RFC4203]     

 
 
C.Hopps et al. - Expires January 2006                                6 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
   Remote SNPP link ID      Link remote part of the TE link identifier 
                            sub-TLV [RFC4203]            
   Signal Type              Technology specific part of the Interface 
                            Switching Capability Descriptor sub-TLV    
                            [RFC4203] 
   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 [RFC4203] 
   Link Capacity            Unreserved bandwidth sub-TLV [RFC3630]
                            Max LSP Bandwidth part of the Interface 
                            Switching Capability Descriptor sub-TLV    
                            [RFC4203] 
   Link Availability        Link Protection sub-TLV [RFC4203] 
   Diversity Support        SRLG sub-TLV [RFC4203] 
   Local Adaptation support see above 
    
                Table 1. TE link Attributes in GMPLS OSPF-TE   
    
   Link Characteristics     GMPLS IS-IS  
   -----------------------  ----------- 
   Local SNPP link ID       Link local part of the TE link identifier 
                            sub-TLV [RFC4205]     
   Remote SNPP link ID      Link remote part of the TE link identifier 
                            sub-TLV [RFC4205]    
   Signal Type              Technology specific part of the Interface 
                            Switching Capability Descriptor sub-TLV    
                            [RFC4205] 
   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 [RFC4205] 
   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 [RFC4205] 
   Diversity Support        SRLG sub-TLV [RFC4205] 
   Local Adaptation support see above 
    
               Table 2. TE link Attributes in GMPLS IS-IS-TE 
    
   Note: Link Attributes represent layer resource capabilities and 
   their utilization i.e. the IGP should be able to advertise these 
   attributes on a per-layer basis. 
    
5.3.2 Node Attributes 
    
   Node attributes are the "Logical Node ID" (described in Section 5.1) 
   and the reachability information described in Section 5.3.3. 
 
 
C.Hopps et al. - Expires January 2006                                7 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
    
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] is restricted to advertisement of Host addresses and not 
   prefixes, and therefore requires enhancement (see below). Hence, in 
   order to advertise blocks of reachable address prefixes a 
   summarization mechanism is additionally required. This mechanism may 
   take the form of a prefix length (that indicates the number of 
   significant bits in the prefix) or a network mask. 
    
   A similar mechanism does not exist for IS-IS. Moreover, the Extended 
   IP Reachability TLV [RFC3784] focuses on IP reachable end-points 
   (terminating points), as its name indicates.   
    
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 need to be 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 are 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 disallows 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 
 
 
C.Hopps et al. - Expires January 2006                                8 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
   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 [RFC2328] prevents inter-area routes (which are learned from 
   area 0) from being passed back to area 0. However, GMPLS makes use of 
   Type 10 (area-local scope) LSAs to propagate TE information 
   [RFC3630], [RFC4202]. 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 a 
   particular piece of routing information has been learned from a 
   higher level RC when 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 a higher level RC.  
    
5.6 Routing Protocol Convergence 
    
   Link state protocols have been designed to propagate detected 
   topological changes (such as interface failures, link attributes 
   modification). The convergence period is short and involves a 
   minimum of routing information exchange. 
    
   Therefore, existing routing protocol convergence involves 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. That is, for [RFC3630], multiple Router 
   Addresses and for [RFC3784] multiple Traffic Engineering 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 of multiple Li's creates the following issue, as there is no 
   longer 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 advertisement 
   needs to indicate the remote Lj value and rely on the initial 
   discovery process to 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 
 
 
C.Hopps et al. - Expires January 2006                                9 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
   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; they are respectively 
   referred to as case 1, 2, 3, and 4.  
    
   In Figure 1 below:  
   - R3 represents an LSR with all components collocated.  
   - R2 shows how the "router" component may be disjoint from the node  
   - 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|                         ------  
                        --  
    
                   Figure 1. Evaluation Case 1, 2 and 3 
    
   Case 1 as represented refers either to direct links between edges or 
   "logical links" as shown in Figure 2 (or any combination of them)  
    
                   ------                        ------  
                  |      |                      |      |  
                  |  L1  |                      |  L2  |  
                  |  :   |                      |  :   |  
                  |  : R1|                      |  : R2|  
   Control Plane   --+---                        --+---  
   Elements          :                             :  
   ------------------+-----------------------------+------------------  
   Data Plane        :                             :  
   Elements          :                             :  
                 ----+-----------------------------+-----  
 
 
C.Hopps et al. - Expires January 2006                               10 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
                |    :                             :     |  
                |   ---            ---            ---    |  
                |  |   |----------| P |----------|   |   |  
             ---+--|   |           ---           |   |---+---  
                |  |   |                         |   |   |  
                |  | P1|-------------------------| P2|   |  
                |   ---                           ---    |  
                 ----------------------------------------  
    
                    Figure 2. Case 1 with Logical Links 
    
   Another case (referred to as Case 4) is constituted by the Abstract 
   Node as represented in Figure 3. There is no internal structure 
   associated (externally) to the abstract node.  
    
                       --------------  
                      |R4            |  
                      |              |  
                      |      L6      |  
                      |       :      |  
                      |    ......    |  
                       ---:------:---  
   Control Plane          :      :  
                   +------+------+------+  
   Data Plane             :      :  
                       ---:------:---  
                      |P8 :      :   |  
                      |  --      --  |  
                    --+-|P |----|P |-+--  
                      |  --      --  |  
                       --------------  
    
                      Figure 3. Case 4: Abstract Node 
    
   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. 
    
7. Summary of Necessary Additions to OSPF and IS-IS  
 
   The following sections summarize the additions to be provided to 
   OSPF and IS-IS in support of ASON routing. 
                                                                 
7.1 OSPFv2 
    
   Reachability        Extend Node Attribute sub-TLVs to support 
                       address prefixes (see Section 5.3.3) 
    
   Link Attributes     Representation of cross/inter-layer 
                       relationships in link top-level link TLV (see 
                       Section 5.3.1)   
    
 
 
C.Hopps et al. - Expires January 2006                               11 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
                       Optionally, provide for per signal-type 
                       bandwidth accounting (see Section 5.3.1).                        
    
   Scoping             TE link advertisements to allow for retrieving 
                       their respective local-remote TE Router_ID 
                       relationship(s) (see Section 5.7) 
    
                       Prefixes part of the reachability 
                       advertisements (using Node Attribute top level 
                       TLV) needs to be associated to their respective 
                       local TE Router_ID (see Section 5.7) 
    
   Hierarchy           Provide a mechanism by which Type 10 Opaque LSA 
                       may carry the information that a particular 
                       piece of routing information has been learned 
                       from a higher level RC when propagated to a 
                       lower level RC (such as to not re-introduce this 
                       information back into a higher level RC) 
    
7.2 IS-IS 
    
   Reachability        Provide for reachability advertisement (in the 
                       form of reachable TE prefixes) 
    
   Link Attributes     Representation of cross/inter-layer 
                       relationships in Extended IS Reachability TLV 
                       (see Section 5.3.1)      
    
                       Optionally, provide for per signal-type 
                       bandwidth accounting (see Section 5.3.1). 
    
   Scoping             Extended IS Reachability TLVs to allow for 
                       retrieving their respective local-remote TE 
                       Router_ID relationship(s) (see Section 5.7) 
 
                       Prefixes part of the reachability advertisements 
                       needs to be associated to their respective local 
                       TE Router_ID (see Section 5.7) 
    
   Hierarchy           Extend the up/down bit mechanisms 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). 
    
8. Security Considerations 
    
   The introduction of a dynamic control plane to an ASON network 
   exposes it to additional security risks that may have been 
   controlled or limited by the use of management plane solutions. The 
   routing protocols play a part in the control plane and may be 
 
 
C.Hopps et al. - Expires January 2006                               12 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
   attacked so that they are unstable, or provide incorrect information 
   for use in path computation or by the signaling protocols. 
    
   Nevertheless, there is no reason why the control plane components 
   cannot be secured, and the security mechanisms developed for the 
   routing protocol and used within the Internet are equally applicable 
   within an ASON context. 
    
   [RFC4258] describes the requirements for security of routing 
   protocols for the Automatically Switched Optical Network. Reference 
   is made to [M.3016] that lays out the overall security objectives of 
   confidentiality, integrity, and accountability, and these are well 
   discussed for the Internet routing protocols in [THREATS]. 
 
   A detailed discussion of routing threats and mechanisms, which are 
   currently deployed in operational networks to counter these  
   threats, is found in [OPSECPRACTICES]. A detailed listing of the 
   device capabilities that can be used to support these practices can 
   be found in [RFC3871]. 
    
9. IANA Considerations 
    
   This draft makes no requests for IANA action. 
 
10. 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. 
 
11. References 
    
11.1 Normative References 
    
   [RFC1195]    R.Callon, "Use of OSI IS-IS for Routing in TCP/IP and 
                Dual Environments", RFC 1195, December 1990. 
         
   [RFC2966]    T.Li, T. Przygienda, and H. Smit et al. "Domain-wide 
                Prefix Distribution with Two-Level IS-IS", RFC 2966, 
                October 2000. 
    
   [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. 
    
   [RFC3630]    D.Katz et al. "Traffic Engineering (TE) Extensions to 
                OSPF Version 2", RFC 3630, September 2003. 
 
 
C.Hopps et al. - Expires January 2006                               13 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
                 
   [RFC3784]    H.Smit and T.Li, "Intermediate System to Intermediate 
                System (IS-IS) Extensions for Traffic Engineering (TE)," 
                RFC 3784, June 2004. 
    
   [RFC3871]    G.Jones, Ed., "Operational Security Requirements for 
                Large Internet Service Provider (ISP) IP Network 
                Infrastructure", RFC 3871, September 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.   
 
   [RFC4202]    K.Kompella (Editor) et al., "Routing Extensions in   
                Support of Generalized Multi-Protocol Label Switching      
                (GMPLS)", RFC 4202, October 2005. 
        
   [RFC4203]    K.Kompella, Y.Rekhter, et al, "OSPF Extensions in  
                Support of Generalized Multi-Protocol Label Switching    
                (GMPLS)", RFC 4203, October 2005.  
    
   [RFC4205]    K.Kompella, Y.Rekhter, et al, "Intermediate System  
                to Intermediate System (IS-IS) Extensions in Support  
                of Generalized Multi-Protocol Label Switching (GMPLS)",  
                RFC 4205, October 2005.  
    
   [RFC4258]    D.Brungard et al. "Requirements for Generalized MPLS 
                (GMPLS) Routing for Automatically Switched Optical 
                Network (ASON)," RFC 4258, November 2005. 
    
11.2 Informative References 
    
   [RFC4394]    D.Fedyk et al., "A Transport Network View of the Link 
                Management Protocol (LMP)," RFC 4394, February 2006. 
    
   [OPSECPRACTICES]  M.Kaeo, "Operational Security Current Practices", 
                Internet Draft (Work in progress), draft-ietf-opsec-
                current-practices-02.txt, October 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. 
    
   [THREATS]    A.Barbir et al., "Generic Threats to Routing 
                Protocols", Internet Draft (work in progress), draft-
                ietf-rpsec-routing-threats-07.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    
 
 
C.Hopps et al. - Expires January 2006                               14 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
                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). 
                 
11. 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 
   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                               15 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
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                               16 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
   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                               17 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
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                               18 

draft-ietf-ccamp-gmpls-ason-routing-eval-03.txt               May 2006 
 
 
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 (2006). 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                               19