idnits 2.17.1 draft-ietf-ipo-ason-02.txt: ** The Abstract section seems to be numbered -(775): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(847): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 document is more than 15 pages and seems to lack a Table of Contents. == There are 15 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 6) being 61 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. ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([4], [2,3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 2002) is 8068 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 21 looks like a reference -- Missing reference section? '2' on line 45 looks like a reference -- Missing reference section? '3' on line 95 looks like a reference -- Missing reference section? '4' on line 418 looks like a reference -- Missing reference section? '5' on line 56 looks like a reference -- Missing reference section? '6' on line 361 looks like a reference -- Missing reference section? '7' on line 374 looks like a reference -- Missing reference section? '8' on line 374 looks like a reference -- Missing reference section? '9' on line 380 looks like a reference -- Missing reference section? '10' on line 421 looks like a reference -- Missing reference section? '11' on line 421 looks like a reference -- Missing reference section? '12' on line 434 looks like a reference -- Missing reference section? '13' on line 434 looks like a reference -- Missing reference section? '14' on line 608 looks like a reference -- Missing reference section? '15' on line 631 looks like a reference -- Missing reference section? '16' on line 661 looks like a reference -- Missing reference section? '17' on line 713 looks like a reference -- Missing reference section? '18' on line 838 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 20 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPO WG O. Aboul-Magd 3 Internet Draft B. Jamoussi 4 Document: draft-ietf-ipo-ason-02.txt S. Shew 5 Category: Informational Nortel Networks 6 Expires: September 2002 7 Gert Grammel 8 Sergio Belotti 9 Dimitri Papadimitriou 10 Alcatel 12 March 2002 14 Automatic Switched Optical Network (ASON) Architecture and Its Related 15 Protocols 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 RFC2026 [1]. 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 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 1. Abstract 38 This draft describes the main architectural principles of the 39 automatic switched optical networks (ASON) work that has recently 40 been approved by the ITU-T [2,3]. ASON architecture defines a set of 41 reference points (interfaces) that allows ASON clients to request 42 network services across those reference points. 44 The protocols that run over ASON interfaces are not specified in 45 [2,3]. IP-based protocols like generalized MPLS (GMPLS) [4], can be 46 considered such that the ASON/ASTN work can benefit from the 47 protocols design work progressing at the IETF. In order to cross- 48 fertilize the discussion the basic concepts are described hereafter. 50 2. Conventions used in this document 52 Aboul-Magd Expires September 2002 1 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 55 this document are to be interpreted as described in RFC-2119 [5]. 57 3. Introduction 59 The existing transport networks provide SONET/SDH and WDM services 60 whose connections are provisioned via network management. This 61 process is both slow (weeks to months) relative to the switching 62 speed and costly to the network providers. 64 An automatic switched optical network (ASON) is an optical/transport 65 network that has dynamic connection capability. It encompasses 66 SONET/SDH, wavelength, and potentially fiber connection services in 67 both OEO and all-optical networks. There are a number of added 68 values related to such a capability: 70 - Traffic engineering of optical channels: Where bandwidth 71 assignment is based on actual demand patterns. 73 - Mesh network topologies and restoration: Mesh network topologies 74 can in general be engineered for better utilization for a given 75 demand matrix. Ring topologies might not be as efficient due to 76 the asymmetry of traffic patterns. 78 - Managed bandwidth to core IP network connectivity: A switched 79 optical network can provide bandwidth and connectivity to an IP 80 network in a dynamic manner compared to the relatively static 81 service available today. 83 - Introduction of new optical services: The availability of switched 84 optical networks will facilitate the introduction of new services 85 at the optical layer. Those services include bandwidth on demand 86 and optical virtual private networks (OVPN). 88 This draft describes the main ASON architecture principles. This 89 work has recently been approved by the ITU-T. 91 4. ASON Architecture Principles 93 This section gives a quick summary of ASON architecture principles 94 as defined in [3]. There is no intention to give a comprehensive 95 account of the architecture. The interested reader may refer to [3] 96 and the references therein. 98 ASON defines a control plan architecture that allows the setup and 99 teardown of calls (and the connections that support a call) as a 100 result of a user request. To achieve global coverage and the support 101 of multiple client types, the architecture is described in terms of 102 components and a set of reference points and rules must be applied 103 at the interface points between clients and the network and between 104 networks. 106 Aboul-Magd Expires September 2002 2 107 4.1 ASON Reference Points 109 In ASON architecture there is the recognition that the optical 110 network control plan will be subdivided into domains that match the 111 administrative domains of the network. The transport plane is also 112 partitioned to match the administrative domains. Within an 113 administrative domain the control plane may be further subdivided, 114 e.g., by actions from the management plane. This allows the 115 separation of resources into, for example, domains for geographic 116 regions, that can be further divided into domains that contain 117 different types of equipment. Within each domain, the control plane 118 may be further sub divided into routing areas for scalability, which 119 may also be further subdivided into sets of control components. The 120 transport plane resources used by ASON will be partitioned to match 121 the sub divisions created within the control plane. 123 The interconnection between domains, routing areas and, where 124 required, sets of control components is described in terms of 125 reference points. The exchange of information across these 126 reference points is described by the multiple abstract interfaces 127 between control components. The physical interconnection is 128 provided by one or more of these interfaces. A physical interface 129 is provided by mapping an abstract interface to a protocol. The 130 reference point between an administrative domain and an end user is 131 the UNI. The reference point between domains is the E-NNI. The 132 reference point within a domain between routing areas and, where 133 required, between sets of control components within routing areas is 134 the I-NNI. Figure 1 shows a possible domain subdivisions and the 135 reference points between them 137 +------+ UNI +-----------+ E-NNI +-----------+ 138 |client|-------| Provider A|-------| Provider B| UNI +------+ 139 +------+ | Domain "1"| | Domain "1"|-----|client| 140 | (I-NNI) | | (I-NNI) | +------+ 141 +-----------+ +-----------+ 142 | / 143 E-NNI | / E-NNI 144 | / 145 +-----------+ 146 +------+ UNI | Provider A| 147 |client|-----| Domain "2"| 148 +------+ | (I-NNI) | 149 +-----------+ 151 Figure 1: ASON/ASTN Global Architecture 153 The difference between the I-NNI and the E-NNI is significant. I-NNI 154 is applied in a single routing area where all equipment support the 155 same routing protocol and detailed routing information could be 156 exchanged between the different nodes. On the other hand E-NNI is 158 Aboul-Magd Expires September 2002 3 159 mainly concerned with reachability between domain that employs 160 different routing and protection methodologies. 162 4.2 Call and Connection Control Separation 164 Call and connection control are treated separately in ASON 165 architecture. Call control is a signaling association between one 166 or more user applications and the network to control the set-up, 167 release, modification and maintenance of sets of connections. Call 168 control is used to maintain the association between parties and a 169 call may embody any number of underlying connections, including 170 zero, at any instance of time. 172 Call control is provided at the ingress/egress of the network or at 173 domain boundaries. Call control is applicable at the E-NNI and UNI 174 reference points. Call and connection control separation allows 175 intermediate (relay) network elements to support only procedures 176 needed for the support of switching connections. Access to call 177 information at domain boundaries allows domains that use different 178 protection or restoration mechanisms to inter-work (e.g. a Metro 179 network using UPSR with a backbone network using Mesh Restoration) 180 without the need for all domains to understand all of the possible 181 protection/restoration schemes. 183 With call and connection control separation a single call may embody 184 a number of connections (more than one) between user applications. 185 This allows for the introduction of enhanced services where a single 186 call is composed of more than one application, e.g. voice and video. 187 There are other situations where this separation between call and 188 connection control is beneficial to the service provider, especially 189 in the areas of restoration and maintenance. In those situations it 190 is cost saving to maintain the call state while restoration actions 191 are underway. 193 4.3 Policy and Security 195 According to the ASON architecture policy is defined as the set of 196 rules applied at a system boundary, and implemented by port 197 controller components. System boundaries may be nested to allow for 198 correct modeling of shared policies with any scope. A system is 199 defined as any (arbitrary) collection of components. In general a 200 system boundary will coincide with a domain boundary, this allows 201 the application of a common policy for all interfaces that cross the 202 domain boundary. The nesting of system boundaries allows the 203 application of additional (more stringent) policies if the domain 204 boundaries are between cost centers within a single network 205 (administration) or between different networks (administrations). 207 Policy is applied at individual interfaces crossing the reference 208 points described before. 210 4.4 Federation 212 Aboul-Magd Expires September 2002 4 213 Connection control across multiple domains requires the cooperation 214 between controllers in the different domains. A federation is 215 defined as the community of domains that co-operate for the purpose 216 of connection management. Two types of federations are defined, 217 joint federation model where one connection controller has authority 218 over connection controllers that reside in different domains. The 219 second model is a co-operative model where there is no concept of a 220 parent connection controller. 222 5. ASON Control Plane Requirements 224 A well-designed control plane architecture should give service 225 providers better control of their network, while providing faster 226 and improved accuracy of circuit set-up. The control plane itself 227 should be reliable, scalable, and efficient. It should also be 228 sufficiently generic to support different technologies and differing 229 business needs and different partitions of functions by vendors 230 (i.e., different packaging of the control plane components). In 231 summary, the control plane architecture should: 233 - Be applicable to a variety of transport network technologies 234 (e.g., SONET/SDH, OTN, PXC). In order to achieve this goal, it is 235 essential that the architecture isolates technology dependent 236 aspects from technology independent aspects, and address them 237 separately. 239 - Be sufficiently flexible to accommodate a range of different 240 network scenarios. This goal may be achieved by partitioning the 241 control plane into distinct components. This, allows vendors and 242 service providers to decide the location of these components, and 243 also allows the service provider to decide the security and policy 244 control of these components. 246 The control plane shall support either switched connections (SC) of 247 soft permenant connections (SPC) of basic connection capability in 248 transport networks. These connection capabilities types are: 250 - Uni-directional point-to-point connection 251 - Bi-directional point-to-point connections 252 - Uni-directional point-to-multipoint connections 254 The control of connectivity is essential to the operation of a 255 transport network. The transport network itself can be described as 256 a set of layer networks, each acting as a connecting function whereby 257 associations are created and removed between the inputs and outputs 258 of the function. These associations are referred to as connections. 259 Three types of connection establishment are defined: provisioned, 260 signaled, and hybrid. 262 Establishment of Provisioned connection is triggered by a management 263 system and is referred to as hard permanent connection. Signaled 265 Aboul-Magd Expires September 2002 5 266 connections is established on demand by the communicating end points 267 using a dynamic protocol message exchange in the form of signaling 268 messages. In hybrid connection a network provides a permanent 269 connection at the edge of the network and utilizes a switched 270 connection within the network to provide end-to-end connections 271 between the permanent connections at the network edges. 273 The most significant difference between the three methods above is 274 the party that sets up the connection. In the case of provisioning, 275 connection set up is the responsibility of the network operator, 276 whilst in the signaled case; connection set-up may also be the 277 responsibility of the end user. Additionally, third party signaling 278 should be supported across a UNI. 280 6. ASON Functional Architecture 282 The components of the control plane architecture are: 284 1. Connection Controller Function (CC): The connection controller is 285 responsible for coordination among the Link Resource Manager, 286 Routing Controller for the purpose of the management and 287 supervision of connection setup, release and modification. 289 2. Routing Controller (RC): The role of the RC is to respond to 290 requests from CC for route information needed to setup a 291 connection, and to respond to requests for topology information 292 for network management purposes. 294 3. Link Resource Management (LRM): The LRM component are responsible 295 for the management of subnetwork links including the allocation 296 and de-allocation of resources, providing topology and status 297 information. 299 4. Traffic Policing (TP): The role of the TP is to check that the 300 incoming user connection is sending traffic according to the 301 parameters agreed upon. 303 5. Call Controller: There are two types of call controller, a 304 calling/called party call controller and a network call 305 controller. The role of the call control is the generation and 306 processing of call requests. 308 6. Protocol Controller (PC): The PC provides the function mapping of 309 the parameters of the abstract interfaces of the control 310 components into messages that are carried by a protocol to support 311 interconnection via an interface. 313 7. ASON Reference Points and GMPLS Protocols 315 The ASON CP as shown in Figure 1 defines a set of interfaces or 316 reference points: 318 Aboul-Magd Expires September 2002 6 319 - User-Network Interface (UNI): UNI runs between the optical client 320 and the network. 322 - Internal Node-to-Node Interface (I-NNI): I-NNI defines the 323 interface between the signaling network elements within the same 324 domain or between routing areas. 326 - External Node-to-Node Interface (E-NNI): E-NNI defines the 327 interface between ASON control planes belonging to different 328 domains. 330 The different ASON interfaces are described in the next few 331 sections. Candidate GMPLS-based protocols for use at the different 332 interfaces are also discussed. 334 7.1 ASON User-Network Interface 336 ASON UNI allows ASON client to perform a number of functions 337 including: 339 - Connection Create: Allows the clients to signal to the network to 340 create a new connection with specified attributes. Those 341 attributes might include bandwidth, protection, restoration, and 342 diversity. 344 - Connection Delete: Allows ASON clients to signal to the network 345 the need to delete an already existing connection. 347 - Connection Modify: Allows ASON clients to signal to the network 348 the need to modify one or more attribute for an already existing 349 connection. 351 - Status Enquiry: Allows ASON clients to enquire the status of an 352 already existing connection. 354 Other functions that might be performed at the ASON UNI are, client 355 registration, address resolution, neighbor and service discovery. 356 Those functions could be automated or manually configured between 357 the network and its clients. 359 Client registration and address resolution are tightly coupled to 360 the optical network address scheme. Requirements for optical network 361 addresses and client names are outlined in [6]. In general the 362 client name (or identification) domain and optical address domain 363 are decoupled. The client id should be globally unique to allow for 364 the establishment of end-to-end connections that encompass multiple 365 administration domains. For security, it is required that the nodal 366 addresses used for routing within an optical domain do not cross 367 network boundaries. The notion of closed user groups should also be 368 included in ASON addressing to allow for the offering of OVPN 369 services. 371 Aboul-Magd Expires September 2002 7 372 ASON UNI realization requires the implementation of a signaling 373 protocol with sufficient capabilities to satisfy UNI functions. Both 374 LDP [7] and RSVP-TE [8] have been extended to be used the signaling 375 protocol across the ASON UNI. The extensions involve the definition 376 of the necessary TLVs or objects to be used for signaling connection 377 attributes specific to the optical layer. New messages are also 378 defined to allow for connection status enquiry. The Optical 379 Internetworking Forum (OIF) has adopted both protocols in its UNI 380 1.0 specification [9]. 382 7.2 ASON Internal Node-to-Node Interface 384 The I-NNI defines the interface between adjacent connection controls 385 (CC) in the same domain or between routing areas. There are two main 386 aspects of I-NNI. Those are signaling and routing. 388 Path selection and setup through the optical network requires a 389 signaling protocol. Transport networks typically utilize explicit 390 routing, where path selection can be done either by operator or 391 software scheduling tools in management systems. IN ASON, end-to-end 392 optical channels (connections) are requested with certain 393 constraints. Path selection for a connection request should employ 394 constrained routing algorithms that balance multiple objectives: 396 - Conform to constraints such as physical diversity, etc. 398 - Load balancing of network traffic to achieve the best utilization 399 of network resources. 401 - Follow policy decisions on routing such as preferred routes. 403 To facilitate the automation of the optical connection setup, nodes 404 in the optical network must have an updated view of its adjacencies 405 and of the utilization levels at the various links of the network. 406 This updated view is sometime referred to as state information. 408 State information dissemination is defined as the manner in which 409 local physical resource information is disseminated throughout the 410 network. First the local physical resource map is summarized into 411 logical link information according to link attributes. This 412 information can then be distributed to the different nodes in the 413 network using the control plane transport network IGP. 415 ASON I-NNI could be based on two key protocols, IP and MPLS. Since 416 MPLS employs the principle of separation between the control and the 417 forward planes, its extension to support I-NNI signaling is 418 feasible. Generalized MPLS [4] defines MPLS extensions to suit types 419 of label switching other than the in-packet label. Those other types 420 include, time slot switching, wavelength and waveband switching, and 421 position switching between fibers. Both CR-LDP [10] and RSVP-TE [11] 422 have been extended to allow for the request and the binding of 423 generalized labels. With generalized MPLS, a label switched path 424 (LSP) is established with the appropriate encoding type (e.g. SONET, 426 Aboul-Magd Expires September 2002 8 427 wavelength, etc.). LSP establishment takes into account specific 428 characteristics that belong to a particular technology. 430 MPLS traffic engineering requires the availability of routing 431 protocols that are capable of summarizing link state information in 432 their databases. Extensions to IP routing protocols, OSPF and IS-IS, 433 in support of link state information for generalized MPLS are 434 described in [12, 13]. 436 7.3 ASON External Node-to-Node Interface 438 E-NNI is the external NNI between different domains. Those domains 439 may belong to the same network administration, or to different 440 administrations. In some sense, E-NNI could be viewed as similar to 441 the UNI interface with some routing functions to allow for the 442 exchange of reachability information between different domains. 444 BGP is the IP based protocol that is commonly deployed between 445 different domains. It could be used to summarize reachability 446 information between different ASON domains in the same manner as it 447 has been in use today for IP networks. BGP is rich in policy which 448 makes a good candidate to satisfy service requirements such as 449 diversity where policies could be used in choosing diverse routes. 451 8. ASON/ASTN CP Transport Network (signaling Network) 453 In this section, we detail some architectural considerations for the 454 makeup of the transport network that is used to transport the 455 control plane information. For circuit-based networks, the ability 456 to have an independent transport network for message transportation 457 is an important requirement. 459 The control network represents the transport infrastructure for 460 control traffic, and can be either in-band or out-of-band. An 461 implication of this is that the control plane may be supported by a 462 different physical topology from that of the underlying ASON. There 463 are fundamental requirements that control networks must satisfy in 464 order to assure that control plane data can be transported in a 465 reliable and efficient manner. In the event of control plane failure 466 (for example, communications channel or control entity failure), 467 while new connection operations will not be accepted, existing 468 connections will not be dropped. Control network failure would still 469 allow dissemination of the failure event to a management system for 470 maintenance purposes. This implies a need for separate notifications 471 and status codes for the control plane and ASON. Additional 472 procedures may also be required for control plane failure recovery. 474 It is recognized that the inter-working of the control networks is 475 the first step towards control plane inter-working. To maintain a 476 certain level of ease, it's desirable to have a common control 477 network for different domains/sub-networks or types of network. 479 Aboul-Magd Expires September 2002 9 480 Typically, control plane and transport functions may co-exist in a 481 network element. However, this may not be true in the case of a 482 third party control. This situation needs further study. 483 Furthermore, addressing issues in the control plane vis-�-vis the 484 transport network is also for further study. 486 ASON CP transport network requirements includes: 488 - Control plane message transport should be secure. This requirement 489 stems from the fact that the information exchanged over the 490 control plane is service-provider specific and security is of 491 utmost importance. 493 - Control message transport reliability has to be guaranteed in 494 almost all situations, even during what might be considered 495 catastrophic failure scenarios of the controlled network. 497 - The control traffic transport performance affects connection 498 management performance. Connection service performance largely 499 depends on its message transport. Time sensitive operations, such 500 as protection switching, may need certain QoS guarantees. 501 Furthermore, a certain level of survivability of the message 502 transport should be provided in case of control network failure. 504 - The control network needs to be both upward and downward scalable 505 in order for the control plane to be scalable. Downward 506 scalability may be envisioned where the ASON network offers 507 significant static connections, reducing the need for an extended 508 control network. 510 - The control plane protocols shall not assume that the signaling 511 network topology is identical to that of the transport network. 512 The control plane protocols MUST operate over a variety of 513 signaling network topologies. 515 Given the above requirements, it is critical that the maintenance of 516 the control network itself not pose a problem to service providers. 517 As a corollary this means that configuration-intensive operations 518 should be avoided for the control network. 520 Common channel signaling links are associated with user channels in 521 the following ways: 523 - Associated, whereby signaling messages related to traffic between 524 two network elements are transferred over signalling links that 525 directly connect the two network elements 526 - Non-associated, whereby signaling messages between two network 527 elements A and B are routed over several signalling links, whilst 528 traffic signals are routed directly between A and B. The 529 signalling links used may vary with time and network conditions 530 - Quasi-associated, whereby signaling messages between nodes A and B 531 follow a predetermined routeing path over several signalling links 532 whilst the traffic channels are routed directly between A and B. 534 Aboul-Magd Expires September 2002 10 535 Associated signaling may be used where the number of traffic channels 536 between two network elements is large, thereby allowing a single 537 signaling channel to be shared amongst a large number of traffic 538 channels. 540 Quasi-associated signaling may be used to improve resiliency. For 541 example consider a signaling channel that has failure mechanisms 542 independent of the traffic channels. Failure of the signaling channel 543 will result in loss of signaling capability for all traffic channels 544 even if all the traffic channels are still functional. Quasi- 545 associated signaling mitigates against this by employing alternative 546 signaling routes. In other words the signaling network must be 547 designed such that failure of a signaling link shall not affect the 548 traffic channels associated with that signaling channel. 550 9. Transport Network Survivability and Protection 552 This section describes the strategies that can be used to maintain 553 the integrity of an existing call in the event of failures within 554 the transport network. The terms �Protection� (replacement of a 555 failed resource with a pre-assigned standby) and �Restoration� 556 (replacement of a failed resource by re-routing using spare 557 capacity) are used to classify these techniques. In general, 558 protection actions complete in the tens of millisecond range, while 559 restoration actions normally complete in times ranging from hundreds 560 of milliseconds to up to a few seconds 562 The ASON control plane provides a network operator with the ability 563 to offer a user calls with a selectable class-of-service (CoS), 564 (e.g., availability, duration of interruptions, Errored Seconds, 565 etc). Protection and restoration are mechanisms (used by the 566 network) to support the CoS requested by the user. The selection of 567 the survivability mechanism (protection, restoration or none) for a 568 particular connection that supports a call will be based on; the 569 policy of the network operator, the topology of the network and the 570 capability of the equipment deployed. Different survivability 571 mechanisms may be used on the connections that are concatenated to 572 provide a call. If a call transits the network of more than one 573 operator then each network should be responsible for the 574 survivability of the transit connections. Connection requests at 575 the UNI or E-NNI will contain only the requested CoS, not an 576 explicit protection or restoration type. 578 The protection or restoration of a connection may be invoked or 579 temporarily disabled by a command from the management plane. These 580 commands may be used to allow scheduled maintenance activities to be 581 performed. They may also be used to override the automatic 582 operations under some exceptional failure conditions. 584 The Protection or Restoration mechanism should: 586 Aboul-Magd Expires September 2002 11 587 - Be independent of, and support any, client type (e.g., IP, ATM, 588 SDH, Ethernet). 589 - Provide scalability to accommodate a catastrophic failure in a 590 server layer, such as a fiber cable cut, which impacts a large 591 number client layer connections that need to be restored 592 simultaneously and rapidly. 593 - Utilize a robust and efficient signaling mechanism, which remains 594 functional even after a failure in the transport or signaling 595 network. 596 - Not rely on functions which are non-time critical to initiate 597 protection or restoration actions. Therefore consideration should 598 be given to protection or restoration schemes that do not depend 599 on fault localization. 601 10. Relationship to GMPLS Architecture 603 The relationship between ASON/ASTN control plane architecture and 604 GMPLS-based protocols is established in section 6, where it has been 605 shown how the different GMPLS protocol could be used for the 606 realization of the different ASON/ASTN external interfaces. 608 Recently, a GMPLS architecture [14] has been introduced. It is 609 important to note that there is no real conflict between GMPLS 610 architecture and the network architecture presented in this draft. 611 ASON/ASTN provides a functional architecture of a control plane that 612 allows the establishment of switched paths in optical networks. It 613 provides the set of external interfaces that are necessary for the 614 ASTN/ASON network to have a global reach. It does that, however, in a 615 protocol independent fashion that can be realized in a different ways 616 provided that its requirements are satisfied. 618 The GMPLS architecture focuses more on the applications of GMPLS- 619 defined protocols, e.g. CR-LDP for the setup of generalized LSP 620 (GLSP) at the different interfaces of the network, e.g. I-NNI, UNI, 621 etc. It does that in a more comprehensible way than what is described 622 in section 6 of this draft. 624 11. Other ASON/ASTN Related ITU Activities 626 This section describes other activities that are currently underway 627 at the ITU and are related to ASON/ASTN architecture. 629 11.1 Common Equipment Management (G.cemr) 631 G.cemr [15] recommendation specifies those Equipment Management 632 Functions (EMF) requirements that are common for SDH and OTN. The 633 equipment management function (EMF) provides the means through which 634 a Network Element Level manager manages the Network Element Function 635 (NEF). 637 These kind of functions are not detailed in the current GMPLS work 638 since it is focused on control plane related aspects. Network 640 Aboul-Magd Expires September 2002 12 641 Management aspects are subjects of other working groups in IETF such 642 as OPS WG. 644 11.1.1 MPLS solution 646 Element Manager functions are not part of the control plane 647 specifications in GMPLS. 649 11.1.2 Requirements 650 - Network management applications shall perform, Fault, 651 Configuration, Accounting, Performance and Service 652 Management (FCAPS). 653 - Path setup can be triggered by means of a Network 654 Management System using control plane mechanisms 655 - For path setup control plane and Network management systems 656 shall cooperate to allow path provisioning by network 657 management as well as provisioning using the control plane. 659 11.2 Data Communications Network (G.7712/Y.1703) 661 In [16] the various functions constituting a telecommunications 662 network can be classified into two broad functional groups. One is 663 the transport functional group which transfers any 664 telecommunications information from one point to another point(s). 665 The other is the control functional group which realizes various 666 ancillary services and operations and maintenance functions. 668 The Data Communications Network (DCN) provides transport for the 669 applications associated with the control functional group. Examples 670 of such applications that are transported by the DCN are: transport 671 network operations/management applications, DCN 672 operations/management applications, Automatic Switched Transport 673 Services (ASTN) control plane applications, voice communications, 674 etc. 676 The IP-based DCN provides Layer 1 (physical), Layer 2 (data-link) 677 and Layer 3 (network) functionality and consists of 678 routing/switching functionality interconnected via links. These 679 links can be implemented over various interfaces, including WAN 680 interfaces, LAN interfaces, and ECCs. 682 This recommendation provides the architecture requirements for an 683 IP-based DCN, the requirements for inter-working between an IP-based 684 DCN and an OSI-based DCN, and the IP-based DCN interface 685 specifications. 687 11.2.1 GMPLS solution 689 Since in GMPLS the signaling and management plane are independent 690 from each other, different kinds of networks can be used for both 691 tasks. Today GMPLS itself can be managed by the use of GMPLS MIB 692 (draft-nadeau-mpls-gmpls-te-mib-00.txt and referenced). In the view 693 of GMPLS each node is capable to process signaling and routing 695 Aboul-Magd Expires September 2002 13 696 messages whereby the topology of the transport network and the 697 control-plane network are the same. 699 11.2.2 Requirements 701 - The management and signaling functions shall be decoupled 702 from each other 703 - the DCN shall support in-fiber-in-band, in-fiber-out-of- 704 band and out-of-fiber/out-of-band signaling for any kind of 705 technology 706 - DCN shall be dimensioned to support fast restoration by 707 providing fast transport of restoration messages. 708 - DCN shall be IP based and support IP addressing. 709 - IP routing mechanisms (OSPF, IS-IS) shall be used 711 11.3 Distributed Connection Management (G.7713/Y.1704) 713 G.7713/Y.1704 [17] Recommendation covers the areas associated with 714 the signalling aspects of automatic switched transport network, such 715 as attribute specifications, the message sets, the interface 716 requirements, the DCM state diagrams, and the interworking functions 717 for the distributed connection management 719 11.3.1 GMPLS solution 721 In GMPLS a permanent communication between the Network devices is 722 established which is anyhow necessary to exchange reachability and 723 traffic-engineering information (e.g. routing protocol provides 724 reachability and TE attributes information). Link bundling plays a 725 key role by augmenting the scalability of the routing protocol. A 726 user device or a management station can optionally trigger a 727 connection setup and initiates a control plane action. 728 1. In a first phase the edge device (where the Trail Termination 729 is located) has to determine the route (trail) either by a 730 route calculation (e.g. explicit route computation through C- 731 SPF) or by receiving a pre-calculated route from an external 732 device e.g. a Traffic Engineering Tool. 733 2. Then it signals the trail request to the involved nodes across 734 the network, reserving the bandwidth without allocating it. 735 3. When bandwidth reservation has been performed the trail is 736 implemented. 738 Some optimizations have also been added in order to speed up the 739 process of implementing the connection. The full procedure is 740 explained in more detail in draft-ietf-mpls-generalized-signaling- 741 05.txt. 743 11.3.2 Requirements 745 GMPLS control plane components could be applied to ASTN to achieve a 746 distributed connection control taking into account draft-ietf-mpls- 747 generalized-signaling-05.txt. 749 Aboul-Magd Expires September 2002 14 750 11.4 Generalized Automatic Discovery (G.7714/Y.1705) 752 G.7714/Y.1705 [18] describes the specifications for automatic 753 discovery (referred to as auto-discovery) to aid distributed 754 connection management (DCM) and routing in the context of 755 automatically switched transport networks (ASTN/ASON). In this 756 recommendation, three major instances of discovery are addressed, 757 (a) adjacency discovery (b) neighbor discovery (c) service 758 discovery. In addition, the results of neighbor discovery are also 759 used for establishing logical adjacencies between nodes at the 760 control plane. 762 11.4.1 Adjacency Discovery 764 Adjacency discovery is described as the process of verifying 765 physical connectivity between two ports on adjacent network elements 766 over a specific physical layer. Depending on the physical packaging 767 of the functions within a network element, two types of associations 768 need to be discovered as part of adjacency discovery. 770 11.4.2 GMPLS Solution 772 Optical Link Interface (OLI) concept and requirement are proposed in 773 conjunction with LMP-WDM protocol to cover the functions provided by 774 adjacency discovery. From the GMPLS perspective, information 775 exchange occurs between a �passive� and an �active� element, such as 776 between a DWDM (OLS) system and an OXC. Ongoing work with ITU 777 referred to as G.VBI (Virtual Backplane Interface) will complete the 778 picture. 780 11.4.3 Requirements 782 - Adjacency discovery should be provided through a simple protocol 783 mechanism for reporting the health and properties of OLSs based 784 on a well-defined set of parameters. 786 - It should be extensible so that we can start with a set of 787 most-needed parameters initially, and be able to extend later by 788 adding new parameter types and new parameters within a type. 790 - The initial focus is on SONET and SDH equipment. However, the 791 OLI must be extensible to support other types of equipment such 792 as Ethernet and G.709 OTN. 794 - The adjacency must be reliable, not only assume a one-to-one 795 relationship between OLS and client i.e., an OLS client will 796 most likely be attached to multiple different OLSs, and a single 797 OLS may have multiple different clients at a single location. 799 11.4.4 Neighbor Discovery 801 [18] Recommendation provides the requirements and message sets for 802 the automatic neighbor for the User-to-Network Interface (UNI), 804 Aboul-Magd Expires September 2002 15 805 Internal Node-to-Node Interface (I-NNI), External Node-to-Node 806 Interface (E-NNI) and Physical Interface (PI). The requirements in 807 this Recommendation specify the discovery process across these 808 interfaces that aid automated connection management. 810 11.4.5 GMPLS solution 812 MPLS is based on an IP-based control plane incorporating protocols 813 defined for routing and neighbor discovery defined in OSPF and IS- 814 IS. To achieve a single control plane across multiple technology 815 layers a single method for neighbor discovery and routing is 816 mandatory. LMP extensions for neighbor discovery have solved the 817 �potential� problem of the usage of a routing protocol at the UNI 818 (when considering for instance OIF UNI 1.0 specification) 820 11.4.6 Requirements 822 - Neighbor Discovery shall be used to detect and maintain Node 823 adjacencies. For this the mechanisms already defined at the 824 IETF for OSPF and IS-IS shall be used. 825 - Topology information and resource information shall be 826 decoupled. While topology information remains unchanged, 827 resource utilization can change dynamically when setting up 828 new path. To support this concept the links between two 829 adjacent nodes shall be bundled. In case of any single link 830 failure within the bundle, the topology information remains 831 stable while the capacity information may change. 832 - The control plane shall detect changes in the resources and 833 enable timely reaction if established path or network 834 resources are affected by this change. 836 11.4.7 Service Discovery 838 [18] provides the requirements and message sets for the automatic 839 service discovery for the User-to-Network Interface (UNI), Internal 840 Node-to-Node Interface (I-NNI), External Node-to-Node Interface (E- 841 NNI) and Physical Interface (PI). The requirements in this 842 Recommendation specifies the discovery process across these 843 interfaces that aid automated connection management. 845 11.4.8 GMPLS solution 847 GMPLS focuses on intra-domain implementation on which OIF based it�s 848 UNI specification. OIF-UNI GMPLS profile can be considered when 849 discussing about UNI implementations. Extensions of LMP enables the 850 exchange of service discovery information at the UNI 1.0 851 specification. 853 11.4.9 Requirements 855 - Service discovery mechanisms shall be aligned with the 856 mechanisms provided by GMPLS such that a seamless 857 integration of UNI and NNI can be supported. 859 Aboul-Magd Expires September 2002 16 860 11.5 OTN routing (G.rtg) 862 A first outline has been presented during the last ITU Q14/SG15 863 meeting, however one doesn�t expect to see a more complete 864 specification prior to Mid-2002. 866 11.5.1 GMPLS solution 868 GMPLS is supposed to be based on OSPF/IS-IS routing mechanisms and 869 more explicitly to the traffic engineering extensions of these 870 protocols like e.g. CSPF. See also: �draft-kompella-ospf-gmpls- 871 extensions-01.txt OSPF Extensions in Support of Generalized MPLS� 872 and �draft-ietf-isis-gmpls-extensions-02.txt IS-IS Extensions in 873 Support of Generalized MPLS�. Today on-going work related to 874 GMPLS/BGP has started as well in order to cover inter-domain routing 875 specification for non-packet based networks (such as draft-parent- 876 optical-bgp-00.txt) It allows also to use explicit or implicit 877 routing. 879 11.5.2 Requirements 881 - Support of explicit and implicit routing 882 - Support of OSPF and ISIS routing protocols for intra-domain 883 and subsequently BGP for inter-domain routing 884 - Support of constrained based routing in order to e.g. 885 Conform to constraints such as physical diversity, Achieve 886 traffic engineering objectives in the transport network. 887 Examples are to adhere to operator policies on routing such 888 as preferred routes or to conform to network specific 889 constraints 891 11.6 OTN Connection Admission Control (G.cac) 893 Connection admission control (CAC) is necessary for authentication of 894 the user and controlling access to network resources. CAC shall be 895 provided as part of the control plane functionality. It is the role 896 of the CAC function to determine if there is sufficient free resource 897 available to allow a new connection. � If there is, the CAC may 898 permit the connection request to proceed, alternatively, if there is 899 not, it shall notify the originator of the connection request that 900 the request has been denied. Connections may be denied on the basis 901 of available free capacity or alternatively on the basis of 902 prioritisation. CAC policies are outside the scope of 903 standardisation.� 905 11.6.1 GMPLS solution 907 Call admission control in the sense of authentication and access 908 control is not explicitly addressed in GMPLS since a trusted 909 relation in a single operator, multi-vendor network is assumed. The 911 Aboul-Magd Expires September 2002 17 912 work related to connection admission is performed e.g. in OIF. 913 Related issues like security of signaling protocols is already 914 included in RSVP-TE and CR-LDP. However, if a given LSP can not be 915 established through the network (for reasons as diverse as resource 916 unavailability, overbooking, control-plane congestion, etc.) it is 917 simply rejected. 919 11.6.2 Requirements 921 None 923 11.7 OTN Link Management (G.lm) 925 No ITU-T contribution available prior to October 2001. 927 11.7.1 GMPLS solution 929 The Link Management Protocol defined in draft-ietf-ccamp-lmp-00.txt 930 is used to manage the resources available between two nodes and to 931 check the connections. It is closely related to the unnumbered 932 interface and bundling concepts described in �draft-kompella-mpls- 933 bundle-05.txt Link Bundling in MPLS Traffic Engineering�. 935 11.7.2 Requirements 937 - Link management shall form a consistent network level resource 938 view between adjacent nodes. 939 - The use of link management shall decouple resource information 940 from topology information which is bound to the bundling 941 concept. 942 - LMP as under definition in IETF (draft-ietf-ccamp-lmp-00.txt) 943 shall be considered for G.lm. 945 12. Security Considerations 947 This draft does not introduce any unknown security issues. 949 13. References 951 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 952 9, RFC 2026, October 1996. 954 2 Mayer, M. Ed., "Requirements for Automatic Switched Transport 955 Networks (ASTN)", ITU G.8070/Y.1301, V1.0, May 2001. 957 3 M. Mayer, Ed., "Architecture for Automatic Switched Optical 958 Networks (ASON)", ITU G.8080/Y1304, V1.0, October 2001 960 Aboul-Magd Expires September 2002 18 961 4 Ashwood-Smith, P. et. al., "Generalized MPLS- Signaling 962 Functional Description", draft-ietf-mpls-generalized-signaling- 963 04.txt, work in progress, May. 2001 965 5 Bradner, S., "Key words for use in RFCs to Indicate Requirement 966 Levels", BCP 14, RFC 2119, March 1997 968 6 Lazar, M. et. al., "Alternate Addressing Proposal", OIF 969 Contribution, OIF2001.21, January 2001. 971 7 Aboul-Magd, O. et. al., "LDP Extensions for Optical User Network 972 Interface (O-UNI) Signaling", draft-ietf-mpls-ldp-uni-optical- 973 01.txt, work in progress, July 2001. 975 8 Yu, J., et. al., "RSVP Extensions in Support of OIF Optical UNI 976 Signaling", draft-yu-mpls-rsvp-oif-uni-00.txt, work in progress, 977 Dec. 2000. 979 9 Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0 980 Signaling Specifications", OIF Contribution, OIF2000.125.7, 981 October 2001 983 10 Ashoowd-Smith, P. et. al., "Generalized MPLS Signaling: CR-LDP 984 Extensions", draft-ietf-mpls-generalized-cr-ldp-03.txt, work in 985 progress, May 2001 987 11 Ashwood-Smith, P. et. al., "Generalized MPLS Signaling: RSVP-TE 988 Extensions", draft-ietf-mpls-generalized-rsvp-te-03.txt, work in 989 progress, May 2000. 991 12 Kompella, K. et. al., "IS-IS Extensions in Support of Generalized 992 MPLS", draft-ietf-isis-gmpls-extensions-01.txt, work in progress, 993 Nov. 2000. 995 13 Kompella, K. et. al., "OSPF Extensions in Support of Generalized 996 MPLS", draft-kompella-ospf-gmpls-extensions-01.txt, work in 997 progress, Nov. 2000. 999 14 Mannie, E., Ed., "Generalized Multi-Protocol Lable Switching 1000 (GMPLS) Architecture" draft-ietf-ccamp-gmpls-architecture-00.txt, 1001 work in progress, June 2001. 1003 15 Draft New RecommendationG.cemr, Common Equipment Management 1004 Function Requirements, ITU, June 2001 1006 16 C. Daloia, Ed., "Architecture and Specification of Data 1007 Communication Network", ITU G.7712/Y.1703, October 2001 1009 17 Z. Lin, Ed., "Distributed Call and Connection Management", ITU 1010 G.7713/Y.1704, October 2001 1012 Aboul-Magd Expires September 2002 19 1013 18 S. Sankaranarayanan, Ed., "Generalized Automatic Discovery 1014 Techniques", ITU G.7714/Y.1705, October 2001. 1016 14. Author's Addresses 1018 Osama Aboul-Magd 1019 Nortel Networks 1020 P.O. Box 3511, Station C 1021 Ottawa, Ontario, Canada 1022 K1Y-4H7 1023 Phone: 613-763-5827 1024 E.mail: Osama@nortelnetworks.com 1026 Bilel Jamoussi 1027 Nortel Networks 1028 600 Technology Park Drive 1029 Billerica, MA 01821, USA 1030 Phone: 978-288-4506 1031 Email: jamoussi@nortelnetworks.com 1033 Stephen Shew 1034 Nortel Networks 1035 P.O. Box 3511, Station C 1036 Ottawa, Ontario, Canada 1037 K1Y-4H7 1038 Phone: 613-763-2462 1039 Email: sdshew@nortelnetworks.com 1041 Gert Grammel 1042 Alcatel 1043 Via Trento 30, 1044 I-20059 Vimercate, Italy 1045 Phone: +39 039 686-4453 1046 Email: gert.grammel@netit.alcatel.it 1048 Sergio Belotti 1049 Alcatel 1050 Via Trento 30, 1051 I-20059 Vimercate, Italy 1052 Phone: +39 039 686-7060 1053 Email: sergio.belotti@netit.alcatel.it 1055 Dimitri Papadimitriou 1056 Alcatel 1057 Francis Wellesplein 1, 1058 B-2018 Antwerpen, Belgium 1059 Phone: +32 3 240-8491 1060 Email: Dimitri.Papadimitriou@alcatel.be 1062 Aboul-Magd Expires September 2002 20 1063 Full Copyright Statement 1065 "Copyright (C) The Internet Society (date). All Rights Reserved. 1066 This document and translations of it may be copied and furnished to 1067 others, and derivative works that comment on or otherwise explain it 1068 or assist in its implmentation may be prepared, copied, published 1069 and distributed, in whole or in part, without restriction of any 1070 kind, provided that the above copyright notice and this paragraph 1071 are included on all such copies and derivative works. However, this 1072 document itself may not be modified in any way, such as by removing 1073 the copyright notice or references to the Internet Society or other 1074 Internet organizations, except as needed for the purpose of 1075 developing Internet standards in which case the procedures for 1076 copyrights defined in the Internet Standards process must be 1077 followed, or as required to translate it into 1079 Aboul-Magd Expires September 2002 21