idnits 2.17.1 draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2003) is 7496 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC 2026' is defined on line 205, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 208, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Wesam Alanqar (Sprint) 3 Internet Draft Deborah Brungard (ATT) 4 Category: Informational Dave Meyer (1-4-5 Net) 5 Lyndon Ong (Ciena) 6 Expiration Date: April 2004 Dimitri Papadimitriou (Alcatel) 7 Jonathan Sadler (Tellabs) 8 Stephen Shew (Nortel) 10 October 2003 12 Requirements for Generalized MPLS (GMPLS) Routing 13 for Automatically Switched Optical Network (ASON) 15 draft-alanqar-ccamp-gmpls-ason-routing-reqts-00.txt 17 Status of this Memo 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC-2026. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. Internet-Drafts are draft documents valid for a maximum of 26 six months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet- Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The Generalized MPLS (GMPLS) suite of protocols has been defined to 40 control different switching technologies as well as different 41 applications. These include support for requesting TDM connections 42 including SONET/SDH and Optical Transport Networks (OTNs). 44 This document concentrates on the routing requirements on the GMPLS 45 suite of protocols to support the capabilities and functionalities 46 of an Automatically Switched Optical Network (ASON). 48 *** This draft is in an early stage and propose only a template to 49 be further developed *** 51 W.Alanqar et al. - Expires April 2004 1 52 1. Contributors 54 This document is the early stage result of the CCAMP Working Group 55 ASON Routing Requirements design team joint effort. 57 2. Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 61 this document are to be interpreted as described in RFC-2119. 63 The reader is also assumed to be familiar with the terminology used 64 in [G.8080] and [G.7715]. 66 3. Introduction 68 The GMPLS suite of protocol provides support for controlling 69 different switching technologies as well as different applications. 70 These include support for requesting TDM connections including 71 SONET/SDH (see ANSI T1.105 and ITU-T G.707, respectively) as well as 72 Optical Transport Networks (see ITU-T G.709). However, there are 73 certain capabilities that are needed to support Automatically 74 Switched Optical Networks (ASON) control planes. Therefore, it is 75 desirable to understand the corresponding requirements for the GMPLS 76 protocol suite. ASON control plane architecture is defined in 77 [G.8080] and ASON routing requirements are identified in [G.7715]. 78 Also, the SG15/Q.14 is working on refining these requirements. 80 This document focuses on the routing requirements for the GMPLS 81 suite of protocols to support the capabilities and functionalities 82 of ASON control planes. It discusses the requirements for GMPLS 83 routing that MAY subsequently lead to additional backward compatible 84 extensions to support the capabilities specified in the above 85 referenced document. A description of backward compatibility 86 considerations is provided in Section 5. Nonetheless, any protocol 87 (in particular, routing) design or suggested protocol extensions is 88 strictly outside the scope of this document. A terminology section 89 (that may be further completed) is provided in the Appendix. 91 The ASON model distinguishes reference points (representing points 92 of protocol information exchange) defined (1) between an 93 administrative domain and a user a.k.a. user-network interface 94 (UNI), (2) between (and when needed within) administrative domains 95 a.k.a. external network-network interface (E-NNI) and, (3) between 96 areas of the same administrative domain and when needed between 97 control components (or simply controllers) within areas a.k.a. 98 internal network-network interface (I-NNI). 100 The ASON routing architectural model is based on the following 101 assumptions: 103 - The information exchanged between routing controllers is subject 105 W.Alanqar et al. - Expires March 2004 2 106 to policy constraints imposed at reference points (E-NNI and I- 107 NNI) 109 - The routing information exchanged between routing domains (i.e. 110 inter-domain) is independent of intra-domain routing protocol 112 - The routing information exchanged between routing domains is 113 independent of intra-domain control distribution choices, e.g. 114 centralized, fully distributed 116 - The routing adjacency topology and transport network topology 117 shall not be assumed to be congruent 119 - Each routing area shall be uniquely identifiable within a 120 carrier's network (constituted by several routing domains) 122 The following functionality is to be supported by GMPLS routing to 123 instantiate ASON routing realization: 124 - support multiple hierarchical levels 125 - support hierarchical routing information dissemination including 126 summarized routing information 127 - support for multiple links between nodes (and allow for link and 128 node diversity) 129 - support architectural evolution in terms of the number of levels 130 of hierarchies, aggregation and segmentation of (control ?) 131 domains 132 - support routing information divided between attributes pertaining 133 to links and nodes (representing either a routing area or 134 sub-network) 136 In addition the behaviour of GMPLS routing is expected to be such 137 that: 138 - it is scalable with respect to the number of links, nodes and 139 routing area hierarchical levels. - what does this means ? is it 140 routing areas and hierarchical levels ? or hierarchical levels of 141 routing areas - 142 - in response to a routing event (e.g. topology update, reachability 143 update), it delivers convergence and damping against flapping 144 - it fulfils the operational security objectives where required 146 4. ASON Requirements for GMPLS Routing 148 The next sections detail the requirements for GMPLS routing to 149 support the following ASON routing functions: 150 - supporting multiple hierarchical levels 151 - support hierarchical routing information dissemination including 152 summarized routing information 153 - support for multiple links between nodes (and allow for link and 154 node diversity) 155 - support architectural evolution in terms of the number of levels 156 of hierarchies, aggregation and segmentation of (control ?) 157 domains 159 W.Alanqar et al. - Expires March 2004 3 160 - support of routing attributes for links and nodes 162 4.1 Multiple Hierarchical Levels 164 TBD. 166 4.2 Hierarchical Routing Information Dissemination 168 TBD. 170 4.3 Multiple Links between Nodes 172 TBD. 174 4.4 Evolution 176 TBD. 178 4.5 Routing Attributes 180 TBD. 182 4.5.1 Link Attributes 184 TBD. 186 4.5.2 Node Attributes 188 TBD. 190 5. Backward Compatibility 192 TBD. 194 6. Security Considerations 196 TBD. 198 7. Acknowledgements 200 The authors would like to thank Kireeti Kompella for having 201 initiated the proposal of an ASON Routing Requirement Design Team. 203 8. References 205 [RFC 2026] S.Bradner, "The Internet Standards Process -- 206 Revision 3", BCP 9, RFC 2026, October 1996. 208 [RFC 2119] S.Bradner, "Key words for use in RFCs to Indicate 209 Requirement Levels", BCP 14, RFC 2119, March 1997. 211 [G.7715] ITU-T Rec. G.7715/Y.1306, "Architecture and 213 W.Alanqar et al. - Expires March 2004 4 214 Requirements for the Automatically Switched Optical 215 Network (ASON)," June 2002. 217 [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 218 Automatically Switched Optical Network (ASON)," 219 November 2001 (and Revision, January 2003). 221 9. Author's Addresses 223 Deborah Brungard (AT&T) 224 Rm. D1-3C22 - 200 S. Laurel Ave. 225 Middletown, NJ 07748, USA 226 Phone: +1 732 420 1573 227 E-mail: dbrungard@att.com 229 Dimitri Papadimitriou (Alcatel) 230 Francis Wellensplein 1, 231 B-2018 Antwerpen, Belgium 232 Phone : +32 3 240 8491 233 E-mail: dimitri.papadimitriou@alcatel.be 235 W.Alanqar et al. - Expires March 2004 5 236 Appendix - Terminology 238 This document makes use of the following terms: 240 Administrative domain: See Recommendation G.805. 242 Control plane: performs the call control and connection control 243 functions. Through signaling, the control plane sets up and releases 244 connections, and may restore a connection in case of a failure. 246 (Control) Domain: represents a collection of entities that are 247 grouped for a particular purpose. G.8080 applies this G.805 248 recommendation concept (that defines two particular forms, the 249 administrative domain and the management domain) to the control 250 plane in the form of a control domain. The entities that are grouped 251 in a control domain are components of the control plane. 253 External NNI (E-NNI): interfaces are located between protocol 254 controllers between control domains. 256 Internal NNI (I-NNI): interfaces are located between protocol 257 controllers within control domains. 259 Link: See Recommendation G.805. 261 Management plane: performs management functions for the Transport 262 Plane, the control plane and the system as a whole. It also provides 263 coordination between all the planes. The following management 264 functional areas are performed in the management plane: performance, 265 fault, configuration, accounting and security management 267 Management domain: See Recommendation G.805. 269 Transport plane: provides bi-directional or unidirectional transfer 270 of user information, from one location to another. It can also 271 provide transfer of some control and network management information. 272 The Transport Plane is layered; it is equivalent to the Transport 273 Network defined in G.805. 275 User Network Interface (UNI): interfaces are located between 276 protocol controllers between a user and a control domain. 278 W.Alanqar et al. - Expires March 2004 6 279 Full Copyright Statement 281 "Copyright (C) The Internet Society (2003). All Rights Reserved. 283 This document and translations of it may be copied and furnished to 284 others, and derivative works that comment on or otherwise explain it 285 or assist in its implementation may be prepared, copied, published 286 and distributed, in whole or in part, without restriction of any 287 kind, provided that the above copyright notice and this paragraph 288 are included on all such copies and derivative works. However, this 289 document itself may not be modified in any way, such as by removing 290 the copyright notice or references to the Internet Society or other 291 Internet organizations, except as needed for the purpose of 292 developing Internet standards in which case the procedures for 293 copyrights defined in the Internet Standards process must be 294 followed, or as required to translate it into languages other than 295 English. 297 The limited permissions granted above are perpetual and will not be 298 revoked by the Internet Society or its successors or assigns. 300 This document and the information contained herein is provided on an 301 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 302 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 303 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 304 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 305 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 307 W.Alanqar et al. - Expires March 2004 7