idnits 2.17.1 draft-doria-gsmp-req-olsr-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 117: '... GSMP MUST include support for all l...' RFC 2119 keyword, line 120: '...the above labels SHOULD also be suppor...' RFC 2119 keyword, line 130: '...el range message MUST be provided. Th...' RFC 2119 keyword, line 153: '... Port types MUST be added to support...' RFC 2119 keyword, line 154: '...iber. Information that MAY need to be...' (13 more instances...) 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 (Feb 2001) is 8464 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '9' is defined on line 338, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-01 -- No information found for draft-many-gmpls-architecture-oo - is the name correct? -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-03) exists of draft-awduche-mpls-te-optical-02 -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2475 (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 1633 (ref. '5') == Outdated reference: A later version (-11) exists of draft-ietf-gsmp-08 == Outdated reference: A later version (-03) exists of draft-many-ip-optical-framework-02 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-07) exists of draft-ietf-gsmp-mib-04 == Outdated reference: A later version (-05) exists of draft-ietf-gsmp-encaps-03 Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Avri Doria 2 GSMP Working Group Kenneth Sundell 3 Informational Track Stephen Shew 4 Nortel Networks 6 Feb 2001 8 Requirements for adding Optical Switch Support to GSMP 9 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as "work 23 in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 32 This memo provides an overview of the requirements on the GSMP 33 protocol for support of optical switching. 35 Internet Draft Req. for Optical Support in GSMP 2001-03-02 37 Table of Contents 39 ABSTRACT............................................................. 1 41 TABLE OF CONTENTS ................................................... 2 43 1. OVERVIEW.......................................................... 3 45 2. LABEL TYPES....................................................... 3 47 3. PORT AND LABEL MANAGEMENT ISSUES ................................. 4 49 4. STATISTICS MESSAGES .............................................. 4 51 5. CONFIGURATION ISSUES ............................................. 4 52 5.1 Switch Configuration ........................................... 4 53 5.2 Port Configuration ............................................. 4 54 5.3 Service Configuration .......................................... 4 55 6. SERVICE MODEL ISSUES ............................................. 5 57 7. ENCAPSULATION ISSUES ............................................. 5 59 8. MIB ISSUES........................................................ 5 61 9. OXC TRANSACTION MODEL ............................................ 5 62 9.1 Serial Transactions ............................................ 5 63 9.2 Bulk Transactions .............................................. 6 64 10. OXC RESTORATION CAPABILITIES .................................... 6 65 10.1 Non-Reserved Protection Links ................................. 6 66 10.2 Reserved Protection Links ..................................... 6 67 11. SECURITY CONSIDERATIONS ......................................... 7 69 REFERENCES........................................................... 7 71 FULL COPYRIGHT STATEMENT ............................................ 9 72 Internet Draft Req. for Optical Support in GSMP 2001-03-02 74 1. Overview 76 This draft is intended to describe the required changes to GSMP 77 for support of optical, SONET/SDH, and spatial switching of IP 78 packets and flows. It is uncertain at this point what the mix of 79 implementations will be, but the possibilities include: IP based 80 optical routers, optical label switches, wavelength routers, and 81 optical cross connects. There are also several different generic 82 models that might be applied to running IP over WDM [1][2]. One 83 item which seems probable, however, is that it will be 84 advantageous to separate the control functions from the data 85 functions in order to provide a more flexible network 86 architecture.[3] 88 In this draft, no position will be taken about the eventual 89 architectural model that will be most appropriate. The only 90 assumption is that the ability to separate the control mechanisms 91 from the data switching is as useful in GMPLS as it is in current 92 MPLS technology. 94 GSMPv3[6] is well suited for providing the control mechanisms 95 necessary for allowing an IP based controller to direct the 96 activities of an optical switch. In order for GSMP to operate 97 between IP controllers and optical switches and cross connects, 98 support for optical labels and service and resource abstractions 99 must be added to GSMP. 101 2. Label Types 103 New labels are needed to identify the entities that are to be 104 switched in the optical fabric. These are longer than GSMPv3 105 labels as they have physical and structural context. As 106 GMPLS[1][2] has had very similar requirements for label formats 107 alignment with GMPLS is proposed. This includes support for: 109 - Digital Carrier Hierarchy (e.g., DS-1, J-1, E1) 111 - SONET and SDH Hierarchy (e.g., OC-3, STM-1, VT1.5, VC-12) 113 - Lambdas 115 - Fibers 117 GSMP MUST include support for all label types as well as for label 118 hierarchies and label lists as defined by GMPLS[1][2]. 120 Bundles of the above labels SHOULD also be supported (e.g., 5 OC- 121 3s) 123 Internet Draft Req. for Optical Support in GSMP 2001-03-02 125 3. Port and Label Management Issues 127 No changes are currently seen as needed in the port management 128 message. 130 An updated label range message MUST be provided. There MUST also 131 be support of multiplexing (e.g. no multiplexing, SONET 132 multiplexing, Gigabit Ethernet multiplexing etc). 134 4. Statistics messages 136 No changes are currently proposed for the statistics messages to 137 support optical switching. 139 5. Configuration Issues 141 5.1 Switch Configuration 143 No changes are currently proposed for the switch configuration 144 messages to support optical switching. 146 5.2 Port Configuration 148 The port configuration message supplies the controller with the 149 configuration information related to a single port. In order to 150 handle the specific port types in a WDM switch, extensive 151 additions will need to be made to this command. 153 Port types MUST be added to support the mix of SONET signals that 154 can operate over a single fiber. Information that MAY need to be 155 conveyed includes[8]: 157 - wavelengths available on the fiber 159 - serial bit rate per wavelength 161 - type of fiber 163 5.3 Service Configuration 165 While new capability sets MUST be added to support quality 166 parameters in optical switches, no changes are foreseen to the 167 service configuration message as its role to carry the service 168 information as defined in the applicable service model. The 169 changes related to the service model will be discussed in section 170 6. 172 Internet Draft Req. for Optical Support in GSMP 2001-03-02 174 6. Service Model Issues 176 While one assumption of using optical media is that bandwidth is 177 plentiful, it should be expected that traffic engineering will be 178 necessary in any case[3]. GSMP provides the means for each 179 connection, or in this each light trail, to be created with 180 specific quality attributes. Capability to control re-timing and 181 re-shaping MUST be added. 183 Currently, the default set of service models in GSMP are all based 184 on the services models defined elsewhere, e.g. the Intserv 185 model[5][7], the Diffserv[4] model, ATM QoS models and the Frame 186 relay forum QoS models. A determination needs to be made of the 187 applicable quality models for optical channel trails. These models 188 MUST then be mapped to the GSMP capability set mechanism. 190 7. Encapsulation issues 192 The working group needs to decide whether a new encapsulation is 193 required. In other words, will all optical switches used in 194 either the MPLS over Optics and the IP over optics applications 195 require that IP be implemented on the control channel connecting 196 the GSMP controller and Optical switch (the GSMP target). If a 197 raw wavelength control connection is to be allowed, a new 198 encapsulation SHOULD be defined. 200 8. MIB issues 202 If a new encapsulation is defined, then the encapsulation group 203 SHOULD be updated. No other changes should be required. 205 9. OXC Transaction Model 207 9.1 Serial Transactions 209 Many existing OXCs use a command interface which assumes a serial 210 transaction model. That is, a new command cannot be issued or 211 processed until the existing command is completed. Under 212 provisioning control via a network management application, and 213 with non-dynamic path setup, this model has been adequate. 215 Moving to a dynamic path setup capability with a distributed 216 control plane, a parallel transaction model is likely required for 217 performance. This is particularly helpful when the performance of 218 setting up a TDM style connection is much slower than setting up 219 an L2 connection table. If the OXC is not able to support a 220 parallel transaction model, a GSMP controller MUST be informed of 221 this and adopt serial transaction behaviour. 223 Internet Draft Req. for Optical Support in GSMP 2001-03-02 225 9.2 Bulk Transactions 227 Again due to the time it may take some OXCs to setup TDM 228 connections relative to L2 fabrics, support for sending multiple 229 transactions in the same message is a useful optimization. When 230 an OXC receives a bulk message, the individual transactions are 231 acted upon and a single reply is sent. If parallel transactions 232 are not supported, bulk messages can improve performance by 233 reducing transaction overhead. Bulk transactions SHOULD be 234 supported. 236 10. OXC Restoration Capabilities 238 To achieve fast link protection performance (e.g., 50 ms after 239 failure detection), SONET/SDH and some WDM systems use hardware 240 based protection schemes (e.g., ring protection). Achieving this 241 level of performance solely using a data control plane such as 242 GMPLS is a serious challenge. An alternate approach is to utilize 243 fast restoration capabilities of an OXC with a dynamic control 244 plane. 246 An implication of this hybrid approach is that extensions are 247 needed to GSMP to provision the behaviour of an OXC in 248 anticipation of a link failure. 250 10.1 Non-Reserved Protection Links 252 An example of protection OXC behaviour is that when a link fails, 253 a backup link may be used to protect traffic on. This backup link 254 could be selected from a set of links, none of which are pre- 255 reserved. A backup link could be shared with one or more 256 "working" links which is a form of 1:n protection. Specifying the 257 set of possible backup links SHOULD be done as an option to the 258 Add-Branch message. 260 When a backup link is used, the control plane (i.e., signalling) 261 may need to know about the new path state in order to notify the 262 operator, or take some other OAM action (e.g., billing, SLA 263 monitoring). An additional GSMP message to inform the controller 264 SHOULD be added to do this. 266 10.2 Reserved Protection Links 268 A more specialized form of restoration called "1+1" reserves a 269 backup link for a given working link. This backup link is not 270 shared with any other working link and traffic is sent over both 271 working and protection links. Specifying the backup link should 272 be done when the Add-Branch message is sent. This SHOULD be an 273 option to that message. When any link in the working path fails, 275 Internet Draft Req. for Optical Support in GSMP 2001-03-02 277 traffic on the working path ceases to be received at end of the 278 path. 280 If an alternate input port is not specified with an original Add- 281 Branch message, it MAY be specified in a subsequent Add-Branch 282 message. In this case, it is useful to include information about 283 existing users of the output port in that Add-Branch message. 284 This helps the OXC immediately learn of the association between 285 the new input port and an existing one. The association is used 286 to enable OXC protection procedures. This capability MUST be added 287 to the add-branch message. 289 Similar contextual information is needed for a Delete-Branch 290 message so that the OXC can determine if a path becomes 291 unprotected. This capability MUST be added to the Delete-branch 292 message. 294 11. Security Considerations 296 The security of GSMP's TCP/IP control channel has been addressed 297 in [10]. Any potential remaining security considerations are not 298 addressed in the current revision of this draft. 300 References 302 [1] Ashwood-Smith, D., et. al., "Generalized MPLS - Signaling 303 Functional Description", Internet Draft draft- 304 ietf-mpls-generalized-signaling-01.txt (work in 305 progress), November 2000. 307 [2] Ashwood-Smith, D., et. al., "Generalized Multi-Protocol 308 Label Switching (GMPLS) Architecture", draft- 309 many-gmpls-architecture-oo.txt (work in 310 progress), February 2001 312 [3] Awduche, D, Rekhter, Y, et. al., "Multi-Protocol Lambda 313 Switching: Combining MPLS Traffic Engineering 314 Control with Optical Crossconnects," draft- 315 awduche-mpls-te-optical-02.txt (work in 316 progress), July, 2000 318 [4] Blake, S., et. al., "An Architecture for Differentiated 319 Services", RFC2475, December 1998 321 [5] Braden, R., "Integrated Services in the Internet 322 Architecture: An Overview", RFC1633, June 1994 324 Internet Draft Req. for Optical Support in GSMP 2001-03-02 326 [6] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General 327 Switch Management Protocol V3," Internet Draft 328 draft-ietf-gsmp-08.txt (work in progress), 329 December 2000 331 [7] J. Wroclawski, "Specification of the Controlled-Load 332 Network Element Service," RFC2211, Sep 1997. 334 [8] Rajagopalan, B., et. al., "IP over Optical Networks: A 335 Framework", draft-many-ip-optical-framework- 336 02.txt (work in progress), November 2000 338 [9] Sjostrand, H, et al, Definitions of Managed Objects for 339 the General Switch Management Protocol (GSMP)," 340 Internet-Draft draft-ietf-gsmp-mib-04 (work in 341 progress), December 2000. 343 [10] Worster, T, et al, "GSMP Packet Encapsulations for ATM, 344 Ethernet and TCP," Internet-Draft draft-ietf- 345 gsmp-encaps-03 (work in progress), December 346 2000. 348 Internet Draft Req. for Optical Support in GSMP 2001-03-02 350 Author's Addresses 352 Avri Doria 353 Nortel Networks 354 600 Technology Park Drive 355 Billerica MA 01821 356 avri@nortelnetworks.com 358 Kenneth Sundell 359 Nortel Networks AB 360 P.O. Box 6701 361 SE-113 85 Stockholm Sweden 362 ksundell@nortelnetworks.com 364 Stephen Shew 365 Nortel Networks 366 PO Box 3511 Station C 367 Ottawa, ON 368 K1Y 4H7 369 Sdshew@nortelnetworks.com 371 Full Copyright Statement 372 "Copyright (C) The Internet Society 2001. All Rights Reserved. 373 This document and translations of it may be copied and 374 furnished to others, and derivative works that comment on or 375 otherwise explain it or assist in its implementation may be 376 prepared, copied, published and distributed, in whole or in 377 part, without restriction of any kind, provided that the above 378 copyright notice and this paragraph are included on all such 379 copies and derivative works. However, this document itself may 380 not be modified in any way, such as by removing the copyright 381 notice or references to the Internet Society or other Internet 382 organizations, except as needed for the purpose of developing 383 Internet standards in which case the procedures for copyrights 384 defined in the Internet Standards process must be followed, or 385 as required to translate it into.