idnits 2.17.1 draft-aboulmagd-ipo-ason-00.txt: ** The Abstract section seems to be numbered 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? == There is 1 instance of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 12) 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. ** The abstract seems to contain references ([2], [3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 19 looks like a reference -- Missing reference section? '2' on line 45 looks like a reference -- Missing reference section? '3' on line 367 looks like a reference -- Missing reference section? '4' on line 58 looks like a reference -- Missing reference section? '5' on line 147 looks like a reference -- Missing reference section? '6' on line 297 looks like a reference -- Missing reference section? '7' on line 319 looks like a reference -- Missing reference section? '8' on line 319 looks like a reference -- Missing reference section? '9' on line 325 looks like a reference -- Missing reference section? '10' on line 370 looks like a reference -- Missing reference section? '11' on line 370 looks like a reference -- Missing reference section? '12' on line 381 looks like a reference -- Missing reference section? '13' on line 381 looks like a reference -- Missing reference section? '14' on line 412 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPO WG O. Aboul-Magd 3 Internet Draft M. Mayer 4 Document: draft-aboulmagd-ipo-ason-00.txt D. Benjamin 5 Category: Informational B. Jamoussi 6 L. Prattico 7 S. Shew 8 Nortel Networks 10 February, 2001 12 Automatic Switched Optical Network (ASON) Architecture and Its Related 13 Protocols 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 1. Abstract 36 This draft describes an architecture for intelligent optical 37 networks. This architecture is called the automatic switched optical 38 networks (ASON). ASON is a client-server architecture with well- 39 defined interfaces that allows clients to request services from the 40 optical network (server). ASON architecture and its generic 41 automatic switched transport networks (ASTN) has been an active 42 study area both at T1X1 and ITU [2]. 44 The protocols that run over ASON interfaces are not specified in 45 [2]. The emerging of IP-based protocols, e.g. generalized MPLS [3], 46 for the control of the optical layer makes it possible for the ASON 47 architecture to benefit from the protocols design work that has been 48 progressing at the IETF. 50 2. Conventions used in this document 52 Aboul-Magd Expires July 2001 1 53 Draft-aboulmagd-ipo-ason-00.txt February 2001 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 57 this document are to be interpreted as described in RFC-2119 [4]. 59 3. Introduction 61 The existing transport networks provide SONET/SDH and WDM services 62 whose connections are provisioned via network management protocols. 63 This process is both slow (weeks to months) relative to the 64 switching speed and costly to the network providers. 66 An automatic switched optical network (ASON) is an optical/transport 67 network that has dynamic connection capability. It encompasses 68 SONET/SDH, wavelength, and potentially fiber connection services in 69 both OEO and all-opical networks. There are a number of added values 70 related to such a capability: 72 - Traffic engineering of optical channels: Where bandwidth 73 assignment is based on actual demand patterns. 75 - Mesh network topologies and restoration: Mesh network topologies 76 can in general be engineered for better utilization for a given 77 demand matrix. Ring topologies might not be as efficient due to 78 the asymmetry of traffic patterns. 80 - Managed bandwidth to core IP network connectivity: A switched 81 optical network can provide bandwidth and connectivity to an IP 82 network in a dynamic manner compared to the relatively static 83 service available today. 85 - Introduction of new optical services: The availability of switched 86 optical networks will facilitate the introduction of new services 87 at the optical layer. Those services include bandwidth on demand 88 and optical virtual private networks (OVPN). 90 This draft describes the ASON architecture. ASON and its generic 91 ASTN has been a topic of active discussion both at the T1X1 and ITU. 92 The draft focuses on ASON control plane, its requirements, and 93 related protocols. 95 4. ASON Architecture: An Overview 97 The ASON network architecture is shown in Figure 1. In this Figure 98 all the components that can form part of ASON are shown. The 99 architecture shown is intended to allow switching of optical network 100 connections within the optical transport network under control of 101 ASON signaling network. 103 There are three separate planes involved in the network: 105 Aboul-Magd Expires July 2001 2 106 Draft-aboulmagd-ipo-ason-00.txt February 2001 108 - A transport plane (TP) 109 - A control plane (CP) 110 - A management plane (MP) 112 +--------------------------+ +--------------+ 113 | ASON Control Plane | | | 114 | | | | 115 UNI | +------+ I-NNI +------+ E-NNI| +------+ | +------+ 116 ------>| OCC |-------| OCC |-|----|----| OCC | | NMI| | 117 | +------+ +------+ | | +------+ |<-->| | 118 | ^ ^ | | ^ | | | 119 +-----|--------------|-----+ +------|-------+ | | 120 | CCI | | | | 121 +-----|--------------|-----+ +------|-------+ | | 122 | v v | | v | | | 123 | +------+ +------+ | | +-----+ |<-->| | 124 | | OXC | | OXC | | PI | | OXC | | NMI+------+ 125 | | |-------| |-----------| | | 126 | +------+ +------+ | | +-----+ | Management 127 | Transport Plane | | | Plane 128 +--------------------------+ +--------------+ 130 OCC = Optical Network Controller UNI = User Network Interface 131 CCI = Connection Control Interface OXC = Optical Cross Connect 132 I-NNI = Internal Node to Node Interface 133 E-NNI = External Node to Node Interface 134 NMI = Network Management Interface 135 PI = Physical Interface 137 Figure 1: Automatic Switching Optical Network (ASON) Architecture 139 The transport plane contains the transport network elements 140 (switches and links) that carry the entity that is switched, i.e. 141 optical connections. End-to-end connections are setup within the 142 transport plane under the control of the ASON control plane (CP). 143 This draft is concerned with the CP part of the ASON architecture. 144 Both the TP and MP are out of the scope of this draft. 146 ASON architecture belongs to client-server models or the overlay 147 network models as defined in [5]. The salient feature of this model 148 is the existence of well-recognized boundaries between client 149 networks and provider domains. Client/provider separation is a 150 direct recognition of today's networking realities where ownership 151 of layer 3 and layer 1 equipment belongs to different organizations. 152 This client/provider domain separation entails the running of 153 different routing instants at each domain. Thus there is no need to 154 share topology information between carriers and their clients. 156 5. ASON Control Plane: General Requirements 158 A well-designed control plane architecture should give service 159 providers better control of their network, while providing faster 160 and improved accuracy of circuit set-up. The control plane itself 162 Aboul-Magd Expires July 2001 3 163 Draft-aboulmagd-ipo-ason-00.txt February 2001 165 should be reliable, scalable, and efficient. It should also be 166 sufficiently generic to support different technologies and differing 167 business needs and different partitions of functions by vendors 168 (i.e., different packaging of the control plane components). In 169 summary, the control plane architecture should: 171 - Be applicable to a variety of transport network technologies 172 (e.g., SONET/SDH, OTN, PXC). In order to achieve this goal, it is 173 essential that the architecture isolate technology dependent 174 aspects from technology independent aspects, and address them 175 separately. 177 - Be sufficiently flexible to accommodate a range of different 178 network scenarios. This goal may be achieved by partitioning the 179 control plane into distinct components. This, allows vendors and 180 service providers to decide the location of these components, and 181 also allows the service provider to decide the security and policy 182 control of these components. 184 The ASON control plane can be divided into several components, 185 namely, resource discovery, state information dissemination, path 186 selection and path management components. These orthogonal 187 functional components work together to complement each other and 188 form an overall architecture. This approach is intended to avoid 189 inappropriate focus upon certain functional components of the 190 architecture, to the inadvertent exclusion of others, that could 191 result in unnecessary dependencies and non-optimal solutions. The 192 basic modules are described below. 194 5.1 Resource Discovery 196 Resource discovery is defined as the transaction that establishes 197 the adjacencies of the port-pairs. Its basic function is address 198 discovery, service discovery, data path connectivity discovery, 199 verification, and management. The role of the resource discovery 200 module is to establish a complete map of physical connectivity 201 including attributes, remote identifiers, and real-time status. The 202 control procedure of this component could be generic, yet, its 203 contents could be technology specific. 205 5.2 State Information Dissemination 207 State information dissemination is defined as the manner in which 208 local physical resource information is disseminated throughout the 209 network. First, the local physical resource map is summarized into 210 logical link information according to link attributes. This 211 information can then be distributed through the network piggybacked 212 onto the control plane transport network IGP (Interior Gateway 213 Protocol). 215 5.3 Path Selection 217 Aboul-Magd Expires July 2001 4 218 Draft-aboulmagd-ipo-ason-00.txt February 2001 220 Transport network routing procedures typically utilize explicit 221 routing, where path selection can be done either by operator, 222 software scheduling tools in management systems. In a switched 223 optical network, end-to-end optical channel connections are 224 requested with certain constraints. Path selection for a connection 225 request should employ constrained routing based algorithms that 226 balance multiple objectives. 228 5.4 Path Management 230 Path management mainly deals with path operations such as connection 231 setup, modification, deletion, query, auto-rerouting, and protection 232 switching/restoration. Control messages could be conveyed through 233 suitable signaling protocols. 235 Network topology information is typically only provided on a link 236 (and typically not at a link-connection) basis. Link connections are 237 not advertised in the topology dissemination component due to 238 drawbacks with respect to lack of scalability. Therefore, the 239 result of a path selection algorithm is also only at the link level. 240 This implies that the local intelligence in the NE must decide upon 241 the actual link connection that is used for that path. 243 6. ASON Control Plane: Interfaces and Protocols 245 The ASON CP as shown in Figure 1 defines a set of interfaces: 247 - User-Network Interface (UNI): UNI runs between the optical client 248 and the network. 250 - Internal Node-to-Node Interface (I-NNI): I-NNI defines the 251 interface between the signaling network elements, i.e. OCC within 252 the switched optical network. 254 - External Node-to-Node Interface (E-NNI): E-NNI defines the 255 interface between ASON control planes in different administration 256 domains. 258 - Connection Control Interface (CCI): The CCI defines the interface 259 between ASON signaling element, i.e. OCC and the transport network 260 element, i.e. the cross connect. 262 The different ASON interfaces are described in the next few 263 sections. Candidate protocols for use at the different interfaces 264 are also discussed. 266 6.1 ASON User-Network Interface 268 ASON UNI allows ASON client to perform a number of functions 269 including: 271 - Connection Create: Allows the clients to signal to the network to 272 create a new connection with specified attributes. Those 274 Aboul-Magd Expires July 2001 5 275 Draft-aboulmagd-ipo-ason-00.txt February 2001 277 attributes might include bandwidth, protection, restoration, and 278 diversity. 280 - Connection Delete: Allows ASON clients to signal to the network 281 the need to delete an already existing connection. 283 - Connection Modify: Allows ASON clients to signal to the network 284 the need to modify one or more attribute for an already existing 285 connection. 287 - Status Enquiry: Allows ASON clients to enquire the status of an 288 already existing connection. 290 Other functions that might be performed at the ASON UNI are, client 291 registration, address resolution, neighbor and service discovery. 292 Those functions could be automated or manually configured between 293 the network and its clients. 295 Client registration and address resolution are tightly coupled to 296 the optical network address scheme. Requirements for optical network 297 addresses and client names are outlined in [6]. In general the 298 client name (or identification) domain and optical address domain 299 are decoupled. The client id should be globally unique to allow for 300 the establishment of end-to-end connections that encompass multiple 301 administration domains. For security, it is required that the nodal 302 addresses used for routing within an optical domain do not cross 303 network boundaries. The notion of closed user groups should also be 304 included in ASON addressing to allow for the offering of OVPN 305 services. 307 Address registration and resolution usually involves some kind of a 308 directory service. The client uses the registration process to 309 register his identification with the provider network for a 310 particular user group or groups. Address resolution involves the 311 process of translating client names to network addresses. Address 312 resolution can be performed at clients, edge network element, or at 313 every administrative boundary entry. It could involves 314 authentication and policy look up to make sure that a client has the 315 necessary credentials to join a user group. 317 ASON UNI realization requires the implementation of a signaling 318 protocol with sufficient capabilities to satisfy UNI functions. Both 319 LDP [7] and RSVP-TE [8] have been extended to be used the signaling 320 protocol across the ASON UNI. The extensions involve the definition 321 of the necessary TLVs or objects to be used for signaling connection 322 attributes specific to the optical layer. New messages are also 323 defined to allow for connection status enquiry. The Optical 324 Internetworking Forum (OIF) has adopted both protocols in its UNI 325 1.0 specifications [9]. 327 6.2 ASON Internal Node-to-Node Interface 329 Aboul-Magd Expires July 2001 6 330 Draft-aboulmagd-ipo-ason-00.txt February 2001 332 The I-NNI defines the interface between adjacent optical connection 333 controls (OCC) in the same network. There are two main aspects of I- 334 NNI. Those are signaling and routing. 336 (Reword) 337 Path selection and setup through the optical network requires a 338 signaling protocol. Transport networks typically utilize explicit 339 routing, where path selection can be done either by operator or 340 software scheduling tools in management systems. IN ASON, end-to-end 341 optical channels (connections) are requested with certain 342 constraints. Path selection for a connection request should employ 343 constrained routing algorithms that balance multiple objectives: 345 - Conform to constraints such as physical diversity, etc. 347 - Load balancing of network traffic to achieve the best utilization 348 of network resources. 350 - Follow policy decisions on routing such as preferred routes. 352 To facilitate the automation of the optical connection setup, nodes 353 in the optical network must have an updated view of its adjacencies 354 and of the utilization levels at the various links of the network. 355 This updated view is sometime referred to as state information. 357 State information dissemination is defined as the manner in which 358 local physical resource information is disseminated throughout the 359 network. First the local physical resource map is summarized into 360 logical link information according to link attributes. This 361 information can then be distributed to the different nodes in the 362 network using the control plane transport network IGP. 364 ASON I-NNI could be based on two key protocols, IP and MPLS. Since 365 MPLS employs the principle of separation between the control and the 366 forward planes, its extension to support I-NNI signaling is 367 feasible. Generalized MPLS [3] defines MPLS extensions to suit types 368 of label switching other than the in-packet label. Those other types 369 include, time slot switching, wavelength and waveband switching, and 370 position switching between fibers. Both CR-LDP [10] and RSVP-TE [11] 371 have been extended to allow for the request and the binding of 372 generalized labels. With generalized MPLS, a label switched path 373 (LSP) is established with the appropriate encoding type (e.g. SONET, 374 wavelength, etc.). LSP establishment takes into account specific 375 characteristics that belong to a particular technology. 377 MPLS traffic engineering requires the availability of routing 378 protocols that are capable of summarizing link state information in 379 their databases. Extensions to IP routing protocols, OSPF and IS-IS, 380 in support of link state information for generalized MPLS are 381 described in [12, 13]. 383 6.3 ASON External Node-to-Node Interface 385 Aboul-Magd Expires July 2001 7 386 Draft-aboulmagd-ipo-ason-00.txt February 2001 388 E-NNI is an inter-domain interface for use between ASON networks 389 that are under different network administrations. It is similar to 390 the UNI interface with some routing functions to allow for the 391 exchange of reachability information between different domains. BGP 392 is an IP based protocol that could be used to summarize reachability 393 information between different ASON domains in the same manner as it 394 has been in use today for IP networks. 396 6.4 ASON Connection Control Interface 398 CCI defines the interface between the ASON signaling element (OCC) 399 and the transport network elements. Connection control information 400 is passed over this interface to establish connections between the 401 ports of the optical transport switch. The CCI is included as part 402 of ASON control plane because it enables switches of various 403 capacities and internal complexities to be part of an ASON node. 405 The protocol running across the CCI must support two essential 406 functions: 408 - Adding and deletion of connections. 410 - Query of port status of the switch. 412 General Switch Management Protocol (GSMP) [14] fits CCI 413 requirements. GSMP is a general-purpose protocol that allows a 414 controller to establish and release connections across a switch. 415 GSMP is well suited for network architectures that employs label 416 swapping in the forwarding plane, e.g. ATM, FR, and MPLS. This 417 property makes GSMP a good fit for generalized label as defined by 418 generalized MPLS. GSMP extensions for generalized MPLS are yet to be 419 worked out. 421 7. ASON CP Transport Network 423 In this section, we detail some architectural considerations for the 424 makeup of the transport network that is used to transport the 425 control plane information. For circuit based networks, the ability 426 to have an independent transport network for message transportation 427 is an important requirement. 429 The control network represents the transport infrastructure for 430 control traffic, and can be either in-band or out-of-band. An 431 implication of this is that the control plane may be supported by a 432 different physical topology from that of the underlying ASON. There 433 are fundamental requirements that control networks must satisfy in 434 order to assure that control plane data can be transported in a 435 reliable and efficient manner. In the event of control plane failure 436 (for example, communications channel or control entity failure), 437 while new connection operations will not be accepted, existing 438 connections will not be dropped. Control network failure would still 439 allow dissemination of the failure event to a management system for 441 Aboul-Magd Expires July 2001 8 442 Draft-aboulmagd-ipo-ason-00.txt February 2001 444 maintenance purposes. This implies a need for separate notifications 445 and status codes for the control plane and ASON. Additional 446 procedures may also be required for control plane failure recovery. 448 It is recognized that the inter-working of the control networks is 449 the first step towards control plane inter-working. To maintain a 450 certain level of ease, it's desirable to have a common control 451 network for different domains/sub-networks or types of network. 453 Typically, control plane and transport functions may co-exist in a 454 network element. However, this may not be true in the case of a 455 third party control. This situation needs further study. 456 Furthermore, addressing issues in the control plane vis-�-vis the 457 transport network is also for further study. 459 ASON CP transport network requirements includes: 461 - Control plane message transport should be secure. This requirement 462 stems from the fact that the information exchanged over the 463 control plane is service-provider specific and security is of 464 utmost importance. 466 - Control message transport reliability has to be guaranteed in 467 almost all situations, even during what might be considered 468 catastrophic failure scenarios of the controlled network. 470 - The control traffic transport performance affects connection 471 management performance. Connection service performance largely 472 depends on its message transport. Time sensitive operations, such 473 as protection switching, may need certain QoS guarantees. 474 Furthermore, a certain level of survivability of the message 475 transport should be provided in case of control network failure. 477 - The control network needs to be both upward and downward scalable 478 in order for the control plane to be scalable. Downward 479 scalability may be envisioned where the ASON network offers 480 significant static connections, reducing the need for an extended 481 control network. 483 Given the above requirements, it is critical that the maintenance of 484 the control network itself not pose a problem to service providers. 485 As a corollary this means that configuration-intensive operations 486 should be avoided for the control network. 488 8. Security Considerations 490 This draft does not introduce any unknown security issues. 492 9. References 494 Aboul-Magd Expires July 2001 9 495 Draft-aboulmagd-ipo-ason-00.txt February 2001 497 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 498 9, RFC 2026, October 1996. 500 2 Mayer, M. Editor, "Architecture for the Automatic Switched 501 Transport Networks", ITU G.astn, Draft V.0.3, Nov. 2000 503 3 Ashwood-Smith, P. et. al., "Generalized MPLS- Signaling 504 Functional Description", draft-ietf-mpls-generalized-signaling- 505 00.txt, work in progress, Oct. 2000 507 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement 508 Levels", BCP 14, RFC 2119, March 1997 510 5 Rajagopalan, B. et. al., "IP over Optical Networks: A Framework", 511 draft-many-ipo-optical-framework-02.txt, work in progress, Nov. 512 2000 514 6 Lazar, M. et. al., "Alternate Addressing Proposal", OIF 515 Contribution, OIF2001.21, January 2001. 517 7 Aboul-Magd, O. et. al., "LDP Extensions for Optical User Network 518 Interface (O-UNI) Signaling", draft-ietf-mpls-ldp-uni-optical- 519 00.txt, work in progress, Dec. 2000 521 8 Yu, J., et. al., "RSVP Extensions in Support of OIF Optical UNI 522 Signaling", draft-yu-mpls-rsvp-oif-uni-00.txt, work in progress, 523 Dec. 2000. 525 9 Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0 526 Signaling Specifications", OIF Contribution, OIF2000.125.3, Dec. 527 2000 529 10 Ashoowd-Smith, P. et. al., "Generalized MPLS Signaling: CR-LDP 530 Extensions", draft-ietf-mpls-generalized-cr-ldp-00.txt, work in 531 progress, Nov. 2000 533 11 Ashwood-Smith, P. et. al., "Generalized MPLS Signaling: RSVP-TE 534 Extensions", draft-ietf-mpls-generalized-rsvp-te-00.txt, work in 535 progress, Nov 2000. 537 12 Kompella, K. et. al., "IS-IS Extensions in Support of Generalized 538 MPLS", draft-ietf-isis-gmpls-extensions-01.txt, work in progress, 539 Nov. 2000. 541 13 Kompella, K. et. al., "OSPF Extensions in Support of Generalized 542 MPLS", draft-kompella-ospf-gmpls-extensions-00.txt, work in 543 progress, Nov. 2000. 545 14 Doria, A. et. al., "Generalized Switch Management Protocol V3", 546 draft-ietf-gsmp-08.txt, work in progress, Nov. 2000. 548 Aboul-Magd Expires July 2001 10 549 Draft-aboulmagd-ipo-ason-00.txt February 2001 551 11. Author's Addresses 553 Osama Aboul-Magd 554 Nortel Networks 555 P.O. Box 3511, Station C 556 Ottawa, Ontario, Canada 557 K1Y-4H7 558 Phone: 623-763-5827 559 E.mail: Osama@nortelnetworks.com 561 Michael Mayer 562 Nortel Networks 563 P.O. Box 3511, Station C 564 Ottawa, Ontario, Canada 565 K1Y-4H7 566 Phone: 613-765-4153 567 Email: mgm@nortelnetworks.com 569 David Benjamin 570 Nortel Networks 571 2351 BOULEVARD ALFRED-NOBEL 572 ST LAURENT, QUEBEC, CANADA 573 H4S-2A9 574 Phone: 514-818-7812 576 Bilel Jamoussi 577 Nortel Networks 578 600 Technology Park Drive 579 Billerica, MA 01821, USA 580 Phone: 978-288-4506 581 Email: jamoussi@nortelnetworks.com 583 Ludo Prattico 584 Nortel Networks 585 P.O. Box 3511, Station C 586 Ottawa, Ontario, Canada 587 K1Y-4H7 588 Phone: 613-763-1254 590 Stephen Shew 591 Nortel Networks 592 P.O. Box 3511, Station C 593 Ottawa, Ontario, Canada 594 K1Y-4H7 595 Phone: 613-763-2462 596 Email: sdshew@nortelnetworks.com 598 Aboul-Magd Expires July 2001 11 599 Draft-aboulmagd-ipo-ason-00.txt February 2001 601 Full Copyright Statement 603 "Copyright (C) The Internet Society (date). All Rights Reserved. 604 This document and translations of it may be copied and furnished to 605 others, and derivative works that comment on or otherwise explain it 606 or assist in its implmentation may be prepared, copied, published 607 and distributed, in whole or in part, without restriction of any 608 kind, provided that the above copyright notice and this paragraph 609 are included on all such copies and derivative works. However, this 610 document itself may not be modified in any way, such as by removing 611 the copyright notice or references to the Internet Society or other 612 Internet organizations, except as needed for the purpose of 613 developing Internet standards in which case the procedures for 614 copyrights defined in the Internet Standards process must be 615 followed, or as required to translate it into 617 Aboul-Magd Expires July 2001 12