CCAMPNetwork Working GroupChris Hopps (Cisco) Internet Draft Lyndon Ong (Ciena)D. Papadimitriou, Ed. Request for Comments: 4652 Alcatel Category: InformationalDimitri Papadimitriou (Alcatel) JonathanL.Ong Ciena J. Sadler(Tellabs) Expiration Date: December 2006 StephenTellabs S. Shew(Nortel) DaveNortel D. Ward(Cisco) MayCisco September 2006 Evaluation ofexistingExisting Routing Protocols againstASON routing requirements draft-ietf-ccamp-gmpls-ason-routing-eval-03.txtAutomatic Switched Optical Network (ASON) Routing Requirements Status ofthisThis MemoBy 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 ofThis memo provides information for the InternetEngineering 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 maximumcommunity. It does not specify an Internet standard ofsix months and may be updated, replaced, or obsoleted by other documents atanytime. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The listkind. Distribution ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.this memo is unlimited. Copyright Notice Copyright (C) Thelist of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.Internet Society (2006). 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 includingSONET/SDHSynchronous Optical Network/Synchronous Digital Hierarchy (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 11.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.IntroductionThere are certainCertain capabilitiesthatare 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 to 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 inAppendix 1Appendices A and B. 2.C.Hopps et al. - Expires January 2006 2 4. Requirements - Overview TheConventions 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. Contributors This document is the result of the CCAMP Working Group ASON Routing Solution design team's 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@nortel.com Dave Ward (Cisco) EMail: dward@cisco.com 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.(i.e., Level N+1 andN)N), includingreachability,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:theThe 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 as 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 3As 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 andnodesnodes, such as a sub-network orRARA, 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 areIGPInterior Gateway Protocol (IGP) (OSPF andIS-IS)Intermediate System to Intermediate System (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 the following reasons: -non-supportNon-support of TE informationexchange: eachexchange. 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 networktopologytopology. - 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 andnetworks 5.1networks. 5.1. Terminology and Identification - Pi is a physical (bearer/data/transport plane)nodenode. - 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]:[RFC3630]: Router_Address (top level) TLV of the Type 1 TE LSA. [RFC 3784]:[RFC3784]: Traffic Engineering Router ID TLV (Type 134) Note:thisThis 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][RFC3630] 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]:[RFC2328]: Router ID (32-bit). [RFC 1195]:[RFC1195]: IS-IS System ID (48-bit) The Router_ID, which is represented by Ri andthatwhich 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 multipleRi'sRis announcing routing information related to a single Li is under evaluation.C.Hopps et al. - Expires January 2006 4Aside from the Li/Pi mappings, these identifiers are not assumed to be in a particular entity relationship except that the Ri may have multipleLiLis 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 moreLi's.Lis. 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 moreLi.Lis. 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 it makes no assumptions about how control plane accessibility to the Si is achieved.5.25.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.35.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 Piidentifiersidentifiers, as these are data plane addresses for which the Li/Pi mapping is kept (link)local - seelocal; see, for instance the transport LMP document [RFC4394] where such an exchange is described. Example:theThe transport plane identifier is the Pi (the identifier assigned to the physical element) that couldbebe, forinstanceinstance, "666B.F999.AF10.222C", whereas the control plane identifier is the Li (the identifier assigned by the control plane), which couldbebe, forinstanceinstance, "192.0.2.1". The control plane exchanges the control plane identifierinformationinformation, but not the transport plane identifier information(i.e.(i.e., not"666B.F999.AF10.222C""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 5Note 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 connectionend-pointsend-points. 2) the identifiers scoped by theLi's i.e.Lis, i.e., referred to as an associated IPv4/IPv6 addressingspace; notespace. Note that these identifiers mayeitherbe either bundled TE link addresses or component linkaddressesaddresses. 3) when using OSPF or ISIS as the IGP in support of traffic engineering,[RFC 3477][RFC3477] RECOMMENDS that the Li value (referred to the "LSR Router ID")tobe set to the TE Router ID value. Therefore, OSPF and IS-IS carry sufficient node identification information without further modification.5.3.15.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 andIS- ISIS-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 concatenatedsignals i.e.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 IDLink localLink-local part of the TE link identifier sub-TLV [RFC4203]C.Hopps et al. - Expires January 2006 6Remote 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 supportseeSee above Table 1. TE linkAttributesattributes in GMPLS OSPF-TE Link Characteristics GMPLS IS-IS ----------------------- ----------- Local SNPP link IDLink localLink-local part of the TE link identifier sub-TLV [RFC4205] Remote SNPP link IDLink remoteLink-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][RFC4205] Link Availability Link Protection sub-TLV [RFC4205] Diversity Support SRLG sub-TLV [RFC4205] Local Adaptation supportseeSee above Table 2. TE linkAttributesattributes 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.25.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 5.3.35.3.3. Reachability Information Advertisement of reachability can be achieved using the techniques described in[OSPF-NODE][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][OSPF-NODE] is restricted to advertisement of Host addresses and not prefixes, and therefore it requires enhancement (see below).Hence,Thus, 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(which 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.45.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.55.5. Dissemination ofrouting informationRouting Information insupportSupport ofmultiple hierarchical levelsMultiple Hierarchal Levels of RAs G.7715.1 does not define specific mechanisms to support multiple hierarchical levels ofRAs,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 levelhierarchy,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 routingC.Hopps et al. - Expires January 2006 8information 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.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 ahigher levelhigher-level RC when propagated to alower levellower-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 ahigher levelhigher-level RC.5.65.6. Routing Protocol Convergence Link state protocols have been designed to propagate detected topological changes (such as interfacefailures,failures and link attributes modification). The convergence period is short and involves a minimum of routing information exchange. Therefore, existing routing protocol convergence involves mechanisms that are sufficient for ASON applications.5.75.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 that is currently part of the top level Link TLV associates the link to the Router_ID. However, having the Ri advertising on behalf of multipleLi'sLis 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 thelink locallink-local andlink remotelink-remote (unnumbered) ID association maybenot be 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 theC.Hopps et al. - Expires January 2006 9local 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 multipleLi's,Lis, 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 ascasecases 1, 2, 3, and 4. In Figure1 below:1, below, - R3 represents an LSR with all components collocated. - R2 shows how the "router" component may be disjoint from thenodenode. - R1 shows how a single "router" may manage multiplenodesnodes. ------------------- ------- |R1 | |R2 | | | | | ------ | L1 L2 L3 | | L4 | |R3 | | : : : | | : | | | | : : : | | : | | L5 | Control ---+-----+-----+--- ---+--- | : | Plane : : : : | : | ----------------+-----+-----+-----------+-------+---+--+- Data : : : : | : | Plane -- : -- -- | -- | ----|P1|--------|P3|--------|P4|------+-|P5|-+- -- \ : / -- -- | -- | \ -- / | | |P2| ------ -- Figure 1. EvaluationCaseCases 1,22, and 3 Case 1 as represented refers either to direct links between edges or to "logical links" as shown in Figure 2 (or any combination ofthem)them). ------ ------ | | | | | L1 | | L2 | | : | | : | | : R1| | : R2| Control Plane --+--- --+--- Elements : : ------------------+-----------------------------+------------------ Data Plane : : Elements : : ----+-----------------------------+-----C.Hopps et al. - Expires January 2006 10| : : | | --- --- --- | | | |----------| 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.referred to as Si, i.e., the control plane entity that processes the signalingmessages (referred to as Si)messages, is not represented in theseFigures.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.17.1. OSPFv2 Reachability Extend Node Attribute sub-TLVs to support address prefixes (see Section5.3.3)5.3.3). Link Attributes Representation of cross/inter-layer relationships in link top-level link TLV (see Section5.3.1) C.Hopps et al. - Expires January 2006 115.3.1). Optionally, provide forper signal-typeper-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 Section5.7)5.7). Prefixes part of the reachabilityadvertisementsadvertisement (using Node Attributetop leveltop-level TLV) needs to be associated totheirits respective local TE Router_ID (see Section5.7)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 ahigher levelhigher-level RC when propagated to alower levellower-level RC(such(so astonot to re-introduce this informationbackinto ahigher level RC) 7.2higher-level RC). 7.2. IS-IS Reachability Provide for reachability advertisement (in the form of reachable TEprefixes)prefixes). Link Attributes Representation of cross/inter-layer relationships in Extended IS Reachability TLV (see Section5.3.1)5.3.1). Optionally, provide forper signal-typeper-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 Section5.7)5.7). Prefixes part of the reachabilityadvertisementsadvertisement needs to be associated totheirits respective local TE Router_ID (see Section5.7)5.7). Hierarchy Extend the up/down bit mechanisms to propagate the summarized topology (see Section5.3),5.3) and 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 beC.Hopps et al. - Expires January 2006 12attacked so that theyare unstable,become 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[M.3016], which lays out the overall security objectives of confidentiality, integrity, andaccountability, and theseaccountability. These are well discussed for the Internet routing protocols in [THREATS]. A detailed discussion of routing threats andmechanisms, whichmechanisms that are currently deployed in operational networks to counter thesethreats,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.10. References11.110.1. Normative References [RFC1195]R.Callon,Callon, R., "Use of OSI IS-IS forRoutingrouting in TCP/IP andDual Environments",dual environments", RFC 1195, December 1990. [RFC2966]T.Li, T.Li, T., Przygienda, T., and H.Smit et al.Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000. [RFC2328]J.Moy,Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2119]S.Bradner,Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3477]K.Kompella et al.Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC3630]D.Katz et al.Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.C.Hopps et al. - Expires January 2006 13[RFC3784]H.SmitSmit, H. andT.Li,T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering(TE),"(TE)", RFC 3784, June 2004. [RFC3871]G.Jones,Jones, G., Ed., "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", RFC 3871, September 2004. [RFC3946]E.Mannie,Mannie, E. andD.Papadimitriou, (Editors) et al.,D. Papadimitriou, "Generalized Multi-Protocol Label Switching (GMPLS) Extensions forSONETSynchronous Optical Network (SONET) andSDH Control,"Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004. [RFC4202]K.Kompella (Editor) et al.,Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4203]K.Kompella, Y.Rekhter, et al,Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC4205]K.Kompella, Y.Rekhter, et al,Kompella, K., Ed., and Y. Rekhter, Ed., "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.Brungard, D., "Requirements for GeneralizedMPLSMulti- Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network(ASON),"(ASON)", RFC 4258, November 2005.11.210.2. Informative References [RFC4394]D.Fedyk et al.,Fedyk, D., Aboul-Magd, O., Brungard, D., Lang, J., and D. Papadimitriou, "A Transport Network View of the Link Management Protocol(LMP),"(LMP)", RFC 4394, February 2006. [OPSECPRACTICES]M.Kaeo,Kaeo, M., "Operational Security Current Practices",Internet Draft (WorkWork inprogress), draft-ietf-opsec- current-practices-02.txt, October 2005.Progress, July 2006. [OSPF-NODE]R.Aggarwal,Aggarwal, R. andK.Kompella,K. Kompella, "Advertising a Router's Local Addresses in OSPF TEExtensions," Internet Draft, (workExtensions", Work inprogress), draft-ietf-ospf-te-node-addr- 02.txt, March 2005.Progress, June 2006. [THREATS]A.Barbir et al.,Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols",Internet Draft (work in progress), draft- ietf-rpsec-routing-threats-07.txt, October 2004.RFC 4593, August 2006. For information on the availability of ITU Documents, please see http://www.itu.int [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture andC.Hopps et al. - Expires January 2006 14Requirements for the Automatically Switched Optical Network(ASON),"(ASON)", June 2002. [G.7715.1] ITU-T Draft Rec. G.7715.1/Y.1706.1, "ASON Routing Architecture and Requirements for Link StateProtocols,"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(ASON)", June 2006. [M.3016] ITU-T Rec. M.3016.0, "Security for the Management Plane: Overview", May 2005. Appendix1:A. ASON Terminology This document makes use of the following terms: Administrativedomain:domain (see RecommendationG.805) forG.805): For the purposes of[G7715.1][G.7715.1], an administrative domain represents the extent of resourceswhichthat 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:performsPerforms the call control and connection control functions. Through signaling, the control plane sets up and releasesconnections,connections and may restore a connection in case of a failure. (Control) Domain:representsRepresents 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):interfacesInterfaces are located between protocol controllers between control domains. Internal NNI (I-NNI):interfacesInterfaces are located between protocol controllers within control domains.Link:Link (see RecommendationG.805) aG.805): A "topological component"whichthat 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:performsPerforms management functions for the Transport Plane, the controlplaneplane, 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,accountingaccounting, and security management Managementdomain:domain (see RecommendationG.805) aG.805): A management domain defines a collection of managed objectswhichthat are grouped to meet organizational requirements according to geography, technology,policypolicy, or other structure, and for a number of functional areas such as fault, configuration,security,accounting, performance, and security (FCAPS), for the purpose of providing control in a consistent manner. Management domains can be disjoint,containedcontained, or overlapping. Assuchsuch, 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 (inC.Hopps et al. - Expires January 2006 16different 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:providesProvides 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):interfacesInterfaces are located between protocol controllers between a user and a control domain. Note:thereThere is no routing function associated with a UNI reference point.C.Hopps et al. - Expires January 2006 17Appendix2:B. ASON Routing Terminology This document makes use of the following terms: Routing Area (RA):aAn RA represents a partition of the dataplaneplane, and its identifier is used within the control plane as the representation of this partition. Per[G.8080] a[G.8080], an RA is defined by a set ofsub- networks,sub-networks, the links that interconnect them, and the interfaces representing the ends of the links exiting that RA.AAn RA may contain smaller RAs inter-connected by links. The limit of subdivision results inaan RA that contains two sub-networks interconnected by a single link. Routing Database (RDB):repositoryRepository for the local topology, network topology, reachability, and other routing information that is updated as part of the routing information exchange and that 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 being protocol independent (Link Resource Manager or LRM, Routing Controller or RC) and protocol specific (Protocol Controller or PC). Routing Controller (RC):handlesHandles (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):suppliesSupplies 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 specificHandles protocol-specific message exchanges according to the reference point over which the information is exchanged(e.g.(e.g., E-NNI,I-NNI),I-NNI) and internal exchanges with the RC. The PC function is protocol dependent.C.Hopps et al. - Expires January 2006 18 Intellectual Property StatementAuthors' Addresses Dimitri Papadimitriou, Ed. Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 2408491 EMail: dimitri.papadimitriou@alcatel.be Lyndon Ong Ciena Corporation PO Box 308 Cupertino, CA 95015 , USA Phone: +1 408 705 2978 EMail: lyong@ciena.com Jonathan Sadler Tellabs 1415 W. Diehl Rd Naperville, IL 60563 EMail: jonathan.sadler@tellabs.com Stephen Shew Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA K2H 8E9 Phone: +1 613 7632462 EMail: sdshew@nortel.com Dave Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: +1-408-526-4000 EMail: dward@cisco.com Full 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. 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. Intellectual Property 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. AcknowledgmentAcknowledgement Funding for the RFC Editor function iscurrentlyprovided by theInternet Society. C.Hopps et al. - Expires January 2006 19IETF Administrative Support Activity (IASA).