idnits 2.17.1 draft-many-carrier-framework-uni-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 39 longer pages, the longest (page 17) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 39 pages 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.) ** There are 9 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 257 has weird spacing: '...th, and other...' == Line 330 has weird spacing: '...done at the c...' == Line 376 has weird spacing: '...g. both acces...' == Line 757 has weird spacing: '...ervices requi...' == Line 855 has weird spacing: '...Section ter...' == (1 more instance...) -- 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 1906 looks like a reference -- Missing reference section? '2' on line 1909 looks like a reference -- Missing reference section? '4' on line 1915 looks like a reference -- Missing reference section? '3' on line 1912 looks like a reference -- Missing reference section? '10' on line 1230 looks like a reference -- Missing reference section? '7' on line 1923 looks like a reference -- Missing reference section? '6' on line 1921 looks like a reference -- Missing reference section? '5' on line 1918 looks like a reference -- Missing reference section? '8' on line 1927 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT 3 Document: draft-many-carrier-framework-uni-00.txt Yong Xue 4 Category: Informational Daniel Awduche 5 Expiration Date: May, 2001 UUNET/WorldCom 7 Monica Lazer 8 John Strand 9 Jennifer Yates 10 AT&T 12 Larry McAdams 13 Cisco Systems 15 Olga Aparicio 16 Roderick Dottin 18 Cable & Wireless Global 20 Rahul Aggarwal 21 Redback Networks 23 Carrier Optical Services Framework and Associated UNI Requirements 25 Status of this Memo 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of Section 10 of RFC2026. Internet-Drafts are 29 Working documents of the Internet Engineering Task Force (IETF), its 30 areas, and its working groups. Note that other groups may also 31 distribute working documents as Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six 34 months and may be updated, replaced, or obsoleted by other documents 35 at any time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Abstract 46 This contribution describes a carriers optical services framework 47 and associated requirements for the User-Network Interface (UNI). It 48 is intended to provide carrier specific service requirements for the 49 automatic switched optical networks to guide the on-going efforts to 50 develop the standard UNI and other interfaces to the optical layer 51 (OL) control plane. Due to time constraints, no attempt has been 52 made to provide detailed comprehensive requirements; instead we 53 focused on topics of particular interest or concern to the carrier 54 community. This is a work-in-progress document and is expected to 55 evolve in near term as new requirements are identified and further 56 studied. 58 Table of Content 60 1. Introduction....................................................3 61 1.1 Value Statement................................................4 62 1.2 Assumptions....................................................4 63 1.3 Objectives.....................................................5 64 2. Reference Models................................................6 65 2.1 Business Models................................................7 66 2.1.1 Provisioned Bandwidth Service (PBS)..........................7 67 2.1.2 Bandwidth-On-Demand Service (BODS)...........................8 68 2.1.3 Optical Virtual Private Network (OVPN).......................9 69 2.2 Network Model.................................................10 70 2.2.1 Optical Network Connections.................................10 71 2.2.2 Network Interfaces..........................................11 72 2.2.3 Inter-Carrier Model.........................................12 73 2.2.3.1 Policy-based Control and Security.........................13 74 2.2.4 Intra-Carrier Model.........................................13 75 2.2.4.1 Sub-Networks..............................................14 76 2.2.4.2 Policy Control and Security...............................14 77 2.2.5 Network Control Plane.......................................14 78 3. Service Requirements...........................................15 79 3.1 Connection operations.........................................16 80 3.2 Connection Granularity........................................17 81 3.3 Connection attributes.........................................19 82 3.3.1 Identification Attributes...................................19 83 3.3.2 Connection characteristic attributes........................22 84 3.3.3 Routing attributes..........................................23 85 3.4 Interface Types...............................................24 86 3.5.1 Physical Entity Naming......................................26 87 3.5.2 IP Naming...................................................26 88 3.5.3 NSAP Naming.................................................26 89 3.6 Directory Services and Address Translation....................26 90 3.7 Access Methods for Services...................................27 91 3.8 Transparent Services Features and Constraints.................27 92 3.8.1 Transparent Optical Connections.............................27 93 3.8.2 Levels of Transparency for Bitstream Connections............28 94 3.9 Other Service Parameters and requirements.....................28 95 3.10 Protection/Restoration Options...............................29 96 3.11 Drop Side Protection.........................................30 97 4. Network Control Functions and Architecture.....................30 99 4.1 Control Plane Functions.......................................30 100 4.2 Control Plane Access..........................................31 101 4.3 Signaling Channels............................................31 102 4.3.1 In-band and Out-of-Band Signaling...........................31 103 4.3.2 Third-party Signaling.......................................32 104 4.4 Routing Functions.............................................32 105 4.4.1 Routing Model...............................................32 106 4.4.1 Routing Protocols...........................................33 107 4.4.3 Routing Constraints.........................................33 108 4.4.3.1 Reachability Routing Constraints..........................34 109 4.4.3.2 Diverse Routing Constraints...............................34 110 4.4.3.3 Other Routing Constraints.................................35 111 4.4.3.4 Routing for OVPN..........................................35 112 4.5 Automatic Discovery Functions.................................35 113 4.5.1 Service Discovery...........................................35 114 4.5.2 End-System Discovery........................................36 115 4.5.3 Communication Mechanism.....................................36 116 5. Security Considerations........................................37 117 6. Acknowledgments................................................37 118 References:.......................................................37 119 Authors' Addresses:...............................................37 121 1. Introduction 123 This document describes, from the carriers perspective, a generic 124 service framework for the optical transport services over automatic 125 switched optical networks (ASON) and associated requirements for the 126 User-Network Interface (UNI) and control plane functions. It 127 includes the consolidated requirements produced by the carrier sub- 128 working group of the OIF Architecture Working Group as described in 129 [1, 2]. This document is intended to provide a service framework and 130 high-level requirements to guide OIF and IEFT for the work on UNI 131 and other interfaces to the Optical Layer (OL) Control Plane. In 132 order to provide timely guidance, no attempt has been made to 133 provide comprehensive or detailed requirements at this time; 134 instead, we have focused on topics of particular interest or concern 135 to the carrier community. We assume that the user of this document 136 is able and willing to derive the more specific requirements 137 necessary to define a product that meets the intent of this 138 document. 140 Since the carrier's requirements for the optical services and 141 networks are still evolving, not all the requirements in this are 142 mandatory for the initial version of the UNI. For your reference, 143 the carrier requirements for the initial OIF UNI 1.0 development are 144 listed in the documents [1] and [2]. 146 In this document, we focus primarily on the SONET/SDH transport of 147 connections with bandwidth of OC-48/STM16 and up. However, the 148 carrier group is also interested in sub-rate extensions down to STS- 150 1 and STM-1, or even lower to VT1.5 and TU-l1. The requirements for 151 transport services based on other framing technologies are also 152 discussed. 154 In this document the key words "MUST", "SHALL", "SHOULD", 155 RECOMMENDED", "MAY", and "OPTIONAL" and their negatives are to be 156 interpreted as described in IETF RFC 2119. 158 1.1 Value Statement 160 Optical networking permits carriers to provide new types of network 161 services not available with other technologies, enabling 162 sophisticated transport applications of (D)WDM based networks 163 (featuring a variety of topologies such as point-to-point, ring and 164 mesh). These new generation networks provide means for the improved 165 use of network resources and the support of high-bandwidth services. 166 Dynamic bandwidth allocation, fast restoration techniques and flow- 167 through provisioning give birth to an assortment of services. 169 Intelligent optical networks contain distributed management 170 capability and subsume many provisioning and data basing functions 171 currently performed by carrier Operations Systems (OS). This allows 172 the rapid establishment and reconfiguration of connections, 173 potentially reducing provisioning times from months to seconds, thus 174 lowering operating costs and providing the means to set and 175 guarantee SLAs and QoS configured on a per-circuit basis to better 176 meet customer's specific needs. 178 The large capacity and great flexibility of such networks enables 179 the support of several degrees of transparency to user traffic at 180 lower cost to the end customer. The new services expected to be 181 enabled as a minimum are bandwidth on demand, point and click 182 provisioning of optical circuits, and optical virtual private 183 networks. 185 The standardized interface between the optical layer and the higher 186 layer data service layers such as IP, ATM, SONET/SDH enables the 187 end-to-end internetworking of the optical channels for conveying 188 user information of varying formats. The use of standardized 189 protocols will make the benefits of the intelligent optical networks 190 available end-to-end, even if several networks are involved. 192 1.2 Assumptions 194 The optical transport network (OTN) has a layered structure 195 consisting of optical channel, multiplex section, and transmission 196 section layers [4]. In the following the generic term 'Optical 197 Layer' is used to represent any of these layers as appropriate. 198 This document does not address the optical network node interface 199 for the OTN (O-NNI), which is adequately addressed in [3]. 201 1) Most Optical Layer (OL) bandwidth growth will be driven by service 202 paths carrying IP-based services. Meeting the needs of these 203 services should be our primary goal. However the OL network will 204 also need to transport service paths carrying a variety of other 205 service types, supported by both cell/packet and non-cell/packet 206 technologies such as ATM, PDH, SONET/SDH. 207 2) An OL network is likely to support a number of user services 208 networks. There will not always be a trust relationship between 209 the OL network operator and these users or between the various 210 users. The security and access control is a big concern to the 211 carriers. 212 3) Interworking across administrative boundaries where there is a 213 trusted relationship will be needed. 214 4) Interworking across administrative boundaries where there is an 215 un-trusted relationship will be needed. 216 5) A business model based on billing for the services provided by the 217 optical layer must be supported. 218 6) Carriers will want to differentiate their services by defining 219 their own "branded" bundles of functionality, service quality, 220 support, and pricing plans. 221 7) The network is a prime asset for carriers. As such, a carrier will 222 not relinquish control of its resources outside of its 223 administrative boundaries. 225 1.3 Objectives 227 The major objectives of the carriers are trying to achieve from the 228 development of automatic switched optical transport networks 229 include: 230 1) Promote a standardized optical network control plane, with its 231 associated interfaces and protocols. Ensure that intelligent 232 optical networking products from different vendors or employing 233 different technologies can interwork at the control plane level. 234 This is not meant to preclude vendor specific extensions so long 235 as the extensions do not degrade total network performance. 236 However it is unacceptable to expect carriers to write software to 237 conceal OL vendor or technology incompatibilities. 238 2) Provide rapid automatic end-to-end provisioning within the optical 239 network, including routing and signaling by the control plane. 240 "End-to-end" is an important part of this objective; the value of 241 rapid provisioning in the core network is greatly reduced if 242 traditional provisioning intervals are encountered in metro and 243 access networks. Hence inter-domain interworking is viewed as 244 being key to realizing many of the hoped-for benefits. It is 245 recognized that rapid inter-domain provisioning must be built upon 246 rapid automatic provisioning within a single domain. In this 247 document "provisioning" refers to network provisioning only and 248 does not necessarily include other customer-facing aspects of 249 provisioning like the establishment of a new account. 250 3) Provide restoration, diverse routing, and other Quality of Service 251 features within the control plane on a per-service-path basis. 253 Per-circuit control of these capabilities is important because of 254 the anticipated diversity of needs of the OL service users. 255 4) Provide policy-based call acceptance and peering policies and 256 support usage-based accounting based on start and termination 257 time, bandwidth, and other resources requested. These 258 capabilities are necessary to support a pay-for-service business 259 model and otherwise safeguard carrier resources, which carriers 260 expect to be basic to their OL plans. 261 5) Support offering carrier-specific "branded" services. A 262 fundamental carrier business need is the ability to put together 263 packages of features, quality of service, support, and pricing, 264 which they can then market. 265 6) Rapid deployment of new technologies and capabilities with no 266 network service disruption. In particular deployment of a new 267 vendor X capability should not depend on vendor Y's willingness to 268 upgrade their control plane software. It is recognized that the 269 part of the network served by vendor Y equipment may not get the 270 benefits of the new capability in this case. 271 7) Protect the security and reliability of the optical layer, and 272 particularly the control plane. The damage, which could be done if 273 this is not accomplished, is beyond measure. 274 8) Provide the ability for the carrier to control usage of its 275 network resources. The carrier will control what network resources 276 are available to individual services or users. Therefore, in the 277 event of capacity shortages this ability will allow the carrier to 278 ensure that critical and priority services get capacity. 279 9) Reduce the need for carrier written OS software through heavy use 280 of open protocols and vendor and third-party software, 281 particularly for network provisioning and restoration. Carrier OSS 282 software development bottlenecks frequently are on the critical 283 path to technology and service innovation. Improvements in this 284 area are at least as important to many carriers as is the prospect 285 of very rapid provisioning. Note however that entire functions 286 need to be off-loaded in most cases; if this is not done the 287 carrier OS function remains, with the added requirement of 288 interfacing with the new control plane software. 289 10) Ensure the scalability of the optical network. Several 290 aspects of scalability are highly important in a carrier's 291 network: 292 - Node scalability: the size of a single node is expected to be 293 sized anywhere between several hundred and several thousands 294 optical termination ports. 295 - Network scalability: the size of an inter-connected network is 296 expected to be anywhere from several to hundred or thousands of 297 nodes. 299 2. Reference Models 301 In this section, three possible optical transport services models 302 and the network reference model for supporting the services are 303 described. 305 2.1 Business Models 307 A business model defines a business enterprise at a high level. It 308 specifies a service concept, the source of revenues, and other 309 critical elements of the proposed business. 311 Responsibility for transport intensive services such as private line 312 is often spread organizationally between a network operations group 313 and a services/marketing group. For the purposes of the description 314 in this document, the transport optical network and related services 315 is considered a profit center, business unit, or stand-alone 316 business. This should help us better integrate service and network 317 needs into a single view. 319 The ability to create "branded" services is a generic requirement 320 for all the specific business models discussed below. By "branded 321 service" we mean a bundle of functionality, service quality, 322 support, and pricing plan. It is highly desirable that the same 323 "branded" service be available ubiquitously throughout a carrier's 324 network even when heterogeneous technologies are used to implement 325 the service. 327 2.1.1 Provisioned Bandwidth Service (PBS) 329 - Service Concept: Enhanced leased/private line services. 330 Provisioning is done at the customer request by the network 331 operator. The specific service functionality offered by a carrier 332 as part of this sort of service would be a carrier choice, but it 333 is natural and desirable that any feature available in the other 334 business models should be invokeable as part of these offerings if 335 so desired This is just saying that any network capability that 336 can be invoked by, say, signaling across the UNI should also be 337 directly accessible by the network operator's network 338 provisioning and network management work centers. This is 339 basically the "point and click" type of service currently proposed 340 by many vendors. 342 - Target Market: Customers unable to establish connections using 343 direct signaling to the network; customers not needing near-real- 344 time provisioning; customers with complex engineering requirements 345 that cannot be handled autonomously by the operator's optical 346 layer control plane; customers requiring connections to off-net 347 locations; end-to-end managed service offered by (or outsourced 348 to) carriers. 350 - Economies and Connection Control: Billing will be based on the 351 bandwidth, restoration and diversity provided, service duration, 352 quality of service, and other characteristics of the connection. 353 Determination of credit-worthiness may also be made at time of 354 connection. 356 - Network Visibility: No customer visibility into the internal 357 topology of the OTN is required; however, information on the 359 health of provisioned circuit and other technical aspects of the 360 circuit may in some circumstances be provided to the user network 361 as a part of the service agreement. 363 - Service Model: During the provisioning process multiple network 364 resources are reserved and dedicated to the specific path. The 365 control interface is either human (e.g., customer calls a customer 366 service representative) or via a customer network management 367 system (e.g., customer may make its request over a secure web site 368 or by logging into a specialized OSS). Any provisioned bandwidth 369 service facility is tracked. The path is data based as an object 370 (or structure) containing information relating to the connection 371 attributes and the physical entities used in creating the path 372 (e.g., ingress and egress, NE ports, cross-office and inter-office 373 facilities). This information is used to reserve network 374 resources at provisioning time, to track performance parameters, 375 and to perform maintenance functions. An end-to-end managed 376 service may involve multiple networks, e.g. both access networks 377 and an inter-city network. In this case provisioning may be 378 initiated by whichever network has primary service responsibility. 380 2.1.2 Bandwidth-On-Demand Service (BODS) 382 - Service Concept: OC-n/STM-n and other facility connections are 383 established and reconfigured in real time. Signaling between the 384 user NE and the optical layer control plane initiates all 385 necessary network activities. A real-time commitment for a future 386 connection may also be established. A standard set of "branded" 387 service options is available. The functionality available is a 388 proper subset of that available to Provisioned Bandwidth Service 389 users and is constrained by the requirement for real-time 390 provisioning, among other things. Availability of the requested 391 connection is contingent on resource availability. 393 - Target Market: ISP's, large intranet, and other data and SDH/SONET 394 networks requiring large point-to-point capacities and having very 395 dynamic demands. 397 - Economics and connection control: Billing will be based on the 398 bandwidth, restoration and diversity provided, service duration, 399 and other characteristics of the connection. The customer's 400 service options and pricing plan may be negotiated as part of the 401 connection control for this service, or may have been decided as 402 part of the contract. 404 - Network Visibility: No customer visibility into the interior of 405 the ON is required; however, information on the health of 406 provisioned circuit and other technical aspects of the circuit may 407 in some circumstances be provided to the user network as a part of 408 the service agreement 410 - Service Model: This service provides support of real-time creation 411 of bandwidth between two end-points. The time needed to set up 412 bandwidth on demand should be on the order of seconds, preferably 413 sub-seconds. In order to dynamically establish connections, the 414 following assumptions need apply: 415 - The end terminals are already physically connected to the 416 network with adequate capacity. Ingress into the network needs 417 to be pre-provisioned for point to point ingress facilities. 418 - Necessary cross-connects throughout the network will be set 419 automatically upon service request. 420 - UNI signaling between user edge device and network edge device 421 is required for all connection end-points. 422 - Request is only completed if: 423 - The request is consistent with the relevant SLAs, 424 - The network can support the requested connection, and 425 - The user edge devices(s) at the other end point(s) accept 426 connection. 427 - The ability to reserve bandwidth, schedule turn-up and takedown 428 of service, and specify QoS constraints and restoration 429 requirements is needed. 430 - Signaling originated from an intermediate office is needed in 431 support of end-to-end managed services. 433 2.1.3 Optical Virtual Private Network (OVPN) 435 Service Concept: The customer contracts for specific network 436 resources (capacity between OXCs, OXC ports, OXC switching 437 resources) and is able to control these resources to establish, 438 disconnect, and reconfigure optical connection connections. In 439 effect they would have a dedicated optical sub-network under their 440 control. 442 Target market: ISP's, large intranets, and other data networks 443 requiring large point-to-point capacities and having very volatile 444 demands who wish to integrate the control of their service and 445 optical layers, business-to-business broadband solution assemblers. 447 Economics and connection control: Billing will be based on the 448 network resources contracted. Network connection acceptance would 449 involve only a check to ensure that the request is in conformance 450 with capacities and constraints specified in the OVPN service 451 agreement. 453 Network Visibility: Real-time information about the state of all 454 resources contracted for would be made available to the customer. 455 Depending on the service agreement, this may include information on 456 both in-effect circuits and spare resources accessible to the 457 customer. 459 Service Model: For future study. 461 2.2 Network Model 463 This section describes optical network models used to provide a 464 reference framework for the discussion of the overall requirements. 466 We assume an optical network (ON) to be composed of a set of optical 467 network elements (ONE) such as Optical Cross-Connects (OXC), Optical 468 Add/Drop Multiplexers (OADM), interconnected in a general mesh 469 topology using point-to-point optical links such as DWDM optical 470 line systems (OLS). An optical network can be partitioned into a set 471 of optical sub-networks interconnected by optical links. An optical 472 sub-network is a subset of the optical network as a result of 473 network partition based on architectural function, topology, 474 technology or other criteria. Note that the optical sub-network is 475 itself an optical network that can be further partitioned, thereby 476 allowing hierarchical optical networks construction in a recursive 477 fashion. 479 A high-level logical carrier optical networking environment consists 480 of an optical network and a set of interconnected user networks of 481 various types such as IP, ATM, and Frame Relay. Carriers provide 482 optical transport services through the establishment of point-to- 483 point optical connections of fixed bandwidth between optical user 484 edge devices. The user networks connect to the optical network via a 485 user edge device (UED) connected to an edge ONE of the optical 486 network. 488 Optical network user devices include different types of network 489 elements (NE) that can use optical connection services, including 490 but not limited to IP routers, ATM switches, Frame Relay switches, 491 Ethernet Switches (1Gbps/10Gbps), SONET Add-Drop Multiplexers (ADM), 492 SONET Digital Cross-Connects (DXC), or SONET Multiplexing Terminals 493 (MT). 495 In abstraction, the optical layer network is confined by a set of 496 access points at which connection services are provided. The 497 connection carries user signals of varying formats and bandwidth 498 between the ingress and egress network access points, at which the 499 user edge devices are connected. A connection across a sub-network 500 is called a sub-network connection (SNC) and a generic end-to-end 501 connection is a concatenation of one or more optical links and SNCs. 503 Optical networking comprises functionality for transmission, 504 multiplexing, routing, switching, protection, and restoration of 505 optical connections carrying a wide range of user signals. 507 2.2.1 Optical Network Connections 509 We distinguish among the following layered end-to-end connections 510 across the optical network as below: 511 - An optical channel defines an end-to-end physical connection 512 between two termination points in the network by concatenating one 513 or more optical links or optical wavelength channels. As such, the 515 optical channel provides the physical path for the optical signals 516 transmission. 517 - An optical path is a logical connection over an optical channel 518 between ingress and egress access points to the optical network 519 based on specified framing such as SONET. It originates and 520 terminates at the point of adaptation of the service layer to the 521 optical network and provides a specific signal transmission 522 service determined by the framing and bit-rate of the connection. 523 The optical connection can be either unidirectional or bi- 524 directional. 525 - A service path is a logical end-to-end connection over an optical 526 path between two service interfaces and it provides service layer 527 connectivity based on the underlying connection framing. As such, 528 the service path generally terminates at the user edge device 529 (UED) termination points. The service path may be either 530 unidirectional or bi-directional. 532 Unless electronic or hybrid optical switching is utilized by the 533 ONE, switched service granularity will be determined by the WDM 534 channel bit rate, usually at OC48 (2.5Gbps) or OC192 (10Gbps) speed. 535 However, support for the sub-rate connection services is required as 536 discussed in the "Service Requirements" section. 538 Due to the nature of the wavelength switching of the optical 539 network, it's either inefficient or impractical to provision and 540 switch sub-rate service paths within an all-optical network. A 541 viable solution to achieve the consolidation/grooming efficiencies 542 across the optical network is to include an optional low-granularity 543 grooming optical networking function in the UNI architecture. 545 This low-granularity interface, called sub-rate UNI (UNI-SR), to the 546 user edge device can be defined as an extension to the UNI, which 547 shall function the same as UNI in all aspects except that it handles 548 efficiently the provisioning and multiplexing/demultiplexing at sub- 549 rate granularity as specified in the service requirements section. 550 Implementation of UNI-SR may be either within the edge ONE or a 551 separate aggregation device between the user edge device and the 552 edge ONE. 554 2.2.2 Network Interfaces 556 Generally speaking, there are two distinct views of the optical 557 network models from a carrier perspective: inter-carrier network 558 model and intra-carrier network model. 559 - The inter-carrier model shows the internetworking between carrier 560 networks across administrative boundaries or between a carrier 561 network and its users 562 - The intra-carrier model shows the internetworking among the 563 optical sub-networks within a carrier network. 565 Throughout this document we differentiate between interface 566 categories as follows: 567 - The User-Network Interface (UNI) is the interface between an 568 optical network service user and the optical network, specifically 569 between the network edge ONE and the UED. 570 - The Network-Network Interface (NNI) is the interface between two 571 optical networks, specifically between the linked edge ONEs of the 572 two interconnected networks. 574 The network interfaces encompass two aspects of the networking 575 functions: user data plane interface and control plane interface. 576 The former concerns about user data transport across of the network 577 interface and the latter concerns about the control aspect across 578 the network interface such as signaling, routing, etc. 580 A discussion of the more generic Network-Node Interface (NNI) 581 representing the interface between two ONEs within an optical 582 network is beyond the scope of this document. 584 Further, it is important to distinguish interfaces based on their 585 architectural functions in order to have finer access and security 586 control capability. 587 - The UNIs and NNIs are called private UNI interfaces and private 588 NNI interfaces (PRI-UN and PRI-NNI for short), if the interfaces 589 are within the administrative boundary of the carrier's optical 590 network. 591 - The UNIs and NNIs are called public UNI interfaces and public NNI 592 (PUB-UNI and PUB-NNI, for short) interfaces, if the interfaces are 593 across the administrative boundaries of the carrier's optical 594 network. 596 The distinction between private and public interfaces is necessary 597 and required. The two types of interfaces define different 598 architectural functions and distinctive level of access, security 599 and trust relationship. Optical networks must have the capability at 600 it's the network boundary interface to define and enforce different 601 level of functional control discussed above. 603 If the connection between a user and the optical network is via a 604 third-party facility instead of a direct optical link, the UNI 605 should still be at optical network access point. The user connection 606 to the optical network via the third-party should be seen as a 607 virtual link and the third-party should provide transparent UNI 608 signaling transmission over the virtual connection. 610 2.2.3 Inter-Carrier Model 612 In the inter-carrier network model, each carrier's optical network 613 is a separate administrative domain. Both the UNI interface between 614 the user and the carrier network and the NNI interface between 615 carrier's network are crossing the carrier's administrative 616 boundaries and therefore are by definition public interfaces. 618 The inter-carrier network model describes the internetworking 619 relationship between the different carrier's optical networks. The 620 optical connection can be: 621 - Between two network users crossing a single carrier's network, or 622 - Between two network users crossing multiple carriers' networks. 624 An optical connection will traverse two UNI interfaces and zero or 625 more NNI interfaces. 627 2.2.3.1 Policy-based Control and Security 629 A configurable policy-based control mechanism is required to 630 regulate and control the information propagation across both UNI and 631 NNI interfaces and the actions allowed on behalf of the users. 633 A configurable policy-based access-control mechanism including 634 authorization and authentication is required at the public UNI. The 635 IETF Common Open Policy Service (COPS) protocol defines a generic 636 policy provisioning framework as defined in the RFC 2748, and should 637 be considered for support policy-based call acceptance, user access 638 authentication and authorization, usage-based accounting, etc. 640 The carrier's optical network is treated as a trusted domain, which 641 is defined as network under a single technical administration with 642 full trust relationship within the network. Within a trusted domain, 643 all the optical network elements and sub-networks are considered to 644 be secure and trusted by each other. 646 2.2.4 Intra-Carrier Model 648 Without loss of generality, the optical network owned by a carrier 649 service operator can be depicted as consisting of one or more 650 optical sub-networks. A special new architectural boundary is 651 introduced between the carrier's optical network and carrier-owned 652 user network equipment. This demarcation line defines the private 653 UNI by definition and these user network devices are called carrier 654 edge device (CED) vs. user edge device (UED) connected to public 655 UNI. A typical business application for this architecture is when a 656 carrier-owned service provider network try to leverage the carrier's 657 optical service network to provide other services. 659 For example, in addition to the optical channel services to the 660 public, a carrier service operator may also leverage its optical 661 bandwidth to offer other data services such as IP, ATM and Frame 662 Relay by attaching a set of carrier edge devices (CED) to its 663 optical core network. The CED equipment is considered to be an 664 internal optical service client. The interconnection topology among 665 the CED equipment should be completely transparent to the users of 666 the data and voice services. 668 2.2.4.1 Sub-Networks 670 There may be many different reasons for more than one optical sub- 671 networks co-existing within a carrier's optical network. Typically, 672 it is a result of business mergers and acquisitions or incremental 673 optical network technology deployment by the carrier. 675 A sub-network may be a single vendor and single technology network. 676 But in general, the carrier's optical network is heterogeneous in 677 terms of equipment vendor and the technology utilized in each sub- 678 network. There are four possible scenarios: 679 - Single vendor and single technology 680 - Single vendor and multiple technologies 681 - Multiple vendor single technology 682 - Multiple vendors and multiple technologies. 684 The interfaces between the CED equipment and the optical network are 685 private UNIs (PRI-UNI) and the interfaces between optical sub- 686 networks within a carrier's administrative domain are private NNIs 687 (PRI-NNI); while the interfaces between the carrier's optical 688 network and its users are public UNI (PUB-UNI) and the interfaces 689 between optical networks of different operators are the public NNI 690 (PUB-NNI). 692 2.2.4.2 Policy Control and Security 694 The whole carrier network should be treated as a trust domain under 695 a single administration. All the sub-networks and CED equipment are 696 considered secure and trusted to each other. 698 The public interfaces and private interfaces shall have different 699 security trust level. The public UNI/NNI in general should have 700 more stringent restrictions in terms routing information exchange, 701 security access control, etc. 703 A configurable policy-based control mechanism is required to 704 regulate and control the information propagation across both types 705 (public and private) of the UNI interface. A configurable policy- 706 based access-control mechanism including authorization and 707 authentication is required at public UNIs. 709 2.2.5 Network Control Plane 711 Technically speaking, networks consist of many layer networks, such 712 as IP, ATM, SONET, and optical fiber networks, that have 713 client/server relationships between them. A lower layer network 714 provides the transport service to its immediate upper layer. The 715 layer independence has been carefully guarded to allow one layer to 716 be modified without impacting the layers above or below it. 718 The intelligence of the network is contained in its control plane 719 and Each layer has its control plane responsible for all the network 721 control function within the layer. There are two aspects of the 722 network control: intra-layer control and inter-layer control. 724 The networking functions, whether distributed or centralized, in 725 each layer network can be divided into three logical network planes 726 responsible for providing network control functions, data 727 transmission functions and network element management functions 728 respectively. 729 - Control Plane: includes the functions related to networking 730 control capabilities such as routing, signaling, and provisioning, 731 as well as resource and service discovery. 732 - Data Plane: includes the functions related to data forwarding and 733 transmission. 734 - Management Plane: includes the functions related to the management 735 functions of network element, networks and network services. 737 However, new capabilities, such as bandwidth on demand and inter- 738 layer protection schemes, require communication among the network 739 layers. This inter-layer communication has been called a layer 740 control plane, but it does not fully control any one of the layer 741 networks. Instead, it provides signaling and other communications 742 between the existing network layer control planes. The IP, ATM, 743 SONET, and optical control planes must each have a gateway interface 744 for signaling across the inter-layer control plane. The protocol 745 employed on the inter-layer control plane may or may not be the same 746 as the protocols used on the network layer control planes. 748 It is the carriers' strong desire for optical network equipment 749 vendors to include as much as possible the control and management 750 functions in regard to connection provisioning and management. This 751 should allow carriers to avoid developing those functions in their 752 management and operation support systems, thus speeding up the 753 deployment of the optical network technology. 755 3. Service Requirements 757 The generic requirements for the optical carrier's services require 758 that a number of different types of users be supported; that rapid 759 provisioning be supported; that various levels of circuit protection 760 be provided; that some form of mesh restoration be supported; and 761 that a high level of manageability and provisioning flexibility be 762 provided for various framed circuits, such as SDH/SONET, Ethernet, 763 Digital wrapper, etc. 765 The optical network is primarily offering high bandwidth 766 connectivity in the form of connections, where a connection is 767 defined to be a fixed bandwidth circuit between two user network 768 elements, such as IP routers or ATM switches, established via the 769 optical network. A connection is also defined by its demarcation 770 from ingress UNI, across the optical network, to egress UNI of the 772 optical network. The behaviors of the connections are defined by 773 their connection attributes. 775 3.1 Connection operations 777 The fundamental actions or operations related to a connection that a 778 user may request from the network are: 779 - request for a new connection 780 - request for the disconnection or tear-down of an established 781 connection 782 - query connection attributes (i.e. obtain current attributes 783 information re: connection) 784 - connection attribute modification (i.e. change a parameter 785 regarding an established connection - e.g. restoration 786 requirements). 788 A connection attribute modification may be either destructive or 789 non-destructive, depending on whether the operation of the circuit 790 has to be interrupted to achieve the desired modification, or not. 792 For each operation executed, appropriate status codes must be 793 returned to the operation requestor. These operations and their 794 associated responses are to be conveyed across the UNI or the 795 network element management interface. 797 In addition, the following requirements need to be considered: 798 - The destination UNI shall support the destination user edge 799 device's decision to accept or reject connection creation requests 800 from the initiating user edge device based on configured policy. 801 - The UNI shall only support the connection initiating user edge 802 device to request connection attribute(s) modification, subject to 803 policies in effect between the user and the network. 804 - Only non-destructive attribute modification requests are 805 acceptable. 806 - Modification of any connection attribute shall be supported only 807 as a network configurable action, subject to established policies 808 and SLAs. 809 - Initialization of the UNI channel shall support determination of 810 modifiable attribute list. 811 - The UNI should support authentication and authorization of the 812 user request for any of the connection operations list above. 814 In addition, there are several actions that need to be supported, 815 which are not directly related to an individual connection, but are 816 necessary for establishing healthy interfaces. The requirements 817 below show some of these actions: 818 - UNI shall support registration and updates by the UNI entity of 819 the edge devices and user interfaces that it controls. 820 - UNI shall support network queries of the user edge devices and 821 vice versa. 823 - UNI shall support failure detection of user edge device or edge 824 ONE. 826 3.2 Connection Granularity 828 Connection service granularity is defined by a combination of 829 framing (e.g., SONET or SDH) and bandwidth of the signal carried 830 over the network for the user. For the time being, connections are 831 assumed at OC-48/STM16 or OC-192/STM64 rates with sub-rate 832 granularity proposed via UNI sub-rate extension. The connection and 833 associated attributes may define the physical characteristics of the 834 optical connection. However, the consumable attribute is bandwidth. 835 In general, there should not be a one-to-one correspondence imposed 836 between the granularity of the service provided and the maximum 837 capacity of the interface to the user. 839 The user should have the ability to consume optical services at sub- 840 rates of the connection. Hence, STS-n, n<48 granularity is desired. 841 Furthermore, there is increasing interest in support for VT/TU rate 842 granularity to allow for rapid provisioning extensions into the 843 edges of the network. 845 The following table lists a recommended set of the SDH and SONET 846 connection services granularity. Any specific vendor implementation 847 needs to support only the subset consistent with its hardware. 849 Table 1, SDH/SONET Connection Granularity 851 SDH SONET TANSPORTED SIGNAL 852 NAME NAME 854 RS64 STS-192 STM-64 (STS-192) signal without 855 Section termination of any OH. 857 RS16 STS-48 STM-16 (STS-48) signal without 858 Section termination of any OH. 860 MS64 STS-192 STM-64 (STS-192); termination of RSOH 861 Line (section OH) possible. 863 MS16 STS-48 STM-16 (STS-48); termination of RSOH 864 Line (section OH) possible. 866 VC-4- STS- VC-4-64c (STS-192c-SPE); termination 867 64c 192c- of RSOH (section OH), MSOH (line OH) 868 SPE and VC-4-64c TCM OH possible. 870 VC-4- STS- VC-4-16c (STS-48c-SPE); termination 871 16c 48c-SPE of RSOH (section OH), MSOH (line OH) 872 and VC-4-16c TCM OH possible. 874 VC-4-4c STS- VC-4-4c (STS-12c-SPE); termination of 875 12c-SPE RSOH (section OH), MSOH (line OH) and 876 VC-4-4c TCM OH possible. 878 VC-4 STS-3c- VC-4 (STS-3c-SPE); termination of 879 SPE RSOH (section OH), MSOH (line OH) and 880 VC-4 TCM OH possible. 882 VC-3 STS-1- VC-3 (STS-1-SPE); termination of RSOH 884 SPE (section OH), MSOH (line OH) and VC-3 885 TCM OH possible. 886 Note: In SDH it could be a higher 887 order or lower order VC-3, this is 888 identified by the sub-addressing 889 scheme. In case of a lower order VC-3 890 the higher order VC-4 OH can be 891 terminated. 893 VC-2 VT6-SPE VC-2 (VT6-SPE); termination of RSOH 894 (section OH), MSOH (line OH), higher 895 order VC-3/4 (STS-1-SPE) OH and VC-2 896 TCM OH possible. 898 - VT3-SPE VT3-SPE; termination of section OH, 899 line OH, higher order STS-1-SPE OH 900 and VC3-SPE TCM OH possible. 902 VC-12 VT2-SPE VC-12 (VT2-SPE); termination of RSOH 903 (section OH), MSOH (line OH), higher 904 order VC-3/4 (STS-1-SPE) OH and VC-12 905 TCM OH possible. 907 VC-11 VT1.5- VC-11 (VT1.5-SPE); termination of 908 SPE RSOH (section OH), MSOH (line OH), 909 higher order VC-3/4 (STS-1-SPE) OH 910 and VC-11 TCM OH possible. 912 1 Gb and 10 Gb granularity shall be supported for 1 Gb/s and 10 Gb/s 913 (WAN mode) Ethernet framing types, if implemented in the hardware. 915 The applications envisioned for the future internetwork range from 916 those controlled from a home set-top box to those employed by a 917 backbone network operator or carrier's carrier. This range of 918 applications requires a great deal of flexibility in managed 919 bandwidth granularity of the new optical internetwork. No single 920 implementation is expected to support management of the full range 921 of bandwidths. The low bandwidth customer applications are likely 922 to require bandwidths as low as 45 Mb/s while backbone networks are 923 likely to provision 2.5 Gb/s and higher, individual optical 924 wavelengths, or groups of optical wavelengths. The lower bandwidth 925 signals might require packet/cell or TDM multiplexing, while the 926 higher bandwidth signals may be managed entirely using optical 927 parameters, except where optical signal regeneration is required. 928 The network equipment employed would differ accordingly, depending 929 on the applications and the bandwidth granularity required. 931 In addition to the SONET/SDH based services defined above, the 932 following connection services should be supported. 933 - 10 Gb/s Ethernet (LAN mode) 934 - digital wrapper (G.709) : ODU1, ODU2, ODU3, OTU1, ... 935 - PDH: DS-0, DS-1, DS-3, ..., E1, E3, (bi-directional). 936 - protocol independent wavelengths, 937 - Transparent: bandwidth defined in MHz. 939 As intelligent optical networks extend the functionality towards the 940 edges of the network in support of sub-rate interfaces (as low as 941 1.5 Mb/s) will require UNI-SR to support VT /TU granularity. 942 Therefore, sub-rate extensions in ONEs supporting sub-rate fabric 943 granularity shall support VT-x/TU-1n granularity down to VT1.5/TU- 944 l1, consistent with the hardware. 946 3.3 Connection attributes 948 A connection request, query, disconnect or attribute change has 949 associated attributes. The following is a list of the attributes 950 associated with a connection. Additionally, we denote whether each 951 attribute is modifiable by the modify command. 953 It is envisioned that these attributes will be negotiated over the 954 signaling channel between the user and the network (i.e. over the 955 UNI or in some cases with the network's management plane). In some 956 cases, not all of the attributes will be available, depending on the 957 services offered and the equipment available. However, the UNI 958 specification should not preclude any attribute. 960 The connection attributes are arbitrarily divided here into three 961 categories, namely identification attributes, connection 962 characteristic attributes and routing constraints attributes. These 963 categories are purely for our own benefit to assist in grouping 964 similar attributes together. The categories would not appear within 965 the messages passed over the UNI. 967 3.3.1 Identification Attributes 969 The first group of attributes are important in the connection 970 establishment process and in ongoing capacity management and 971 maintenance activities. 972 - connection identifier: a globally unique identifier for the 973 connection. This identifier will be assigned by the network. The 974 globally unique connection identifier will be created using a 975 globally unique carrier identifier (identifying the carrier from 976 which the connection request is sourced) and a carrier unique 977 connection identifier. This attribute is not modifiable (i.e. 978 cannot be modified using the modify command). 980 - contract identifier: an identifier by which we can refer to the 981 service contract which "owns" the connection. This field will be 982 externally provided (i.e. not calculated within the optical 983 network control plane) and will not necessarily have to be unique. 984 It is important for connection acceptance, billing, and 985 appropriate support for SLAs etc. The contract identifier with 986 associated SLA will be used to validate permissibility of 987 connection request (e.g. checking consistency between pre- 988 specified SLA and requested connection priority). The contract 989 identifier should have a sub-field to specify the customer / user 991 group which "owns" the contract. This attribute is not 992 modifiable. 994 - user group identifier: identifier specifying groups of users that 995 are associated in a group. This identifier is particularly 996 important for virtual private optical networks (VPONs). This 997 attribute is not modifiable. 999 - connection status: describes the state of the connection and is 1000 used to convey this information to the user on their request 1001 (query attributes request). The states defined are active, 1002 pending, scheduled (reserved), inactive or unknown. This 1003 attribute is not modifiable. 1005 - connection schedule: the date/time when the connection is desired 1006 to be in service, and the earliest and latest date/time when the 1007 connection will be disconnected. This attribute may also be 1008 recurring to indicate repeated scheduling (e.g. scheduling 1009 recurring connection setup). Thus, the connection schedule will 1010 include parameters regarding connection start time, connection 1011 duration, recurrence interval (time between successive connection 1012 commencements) and the recurrence duration (the interval over 1013 which connections will be established). The default values will 1014 be immediate connection establishment, infinite recurrence 1015 interval (i.e. non-recurring), infinite holding time (i.e. an 1016 explicit tear down request is required for tearing down the 1017 connection) and zero recurrence duration (i.e. non-recurring). 1018 The disconnect information is needed for capacity management; it 1019 might also be a factor in determining charges. This attribute is 1020 non-destructively modifiable. The minimum default values support 1021 is required. (i.e. immediate establishment, infinite recurrence 1022 intervals and infinite holding time). 1024 - destination name: the name used to identify the node to which the 1025 connection is to be established. Various naming schemes can be 1026 used to describe the destination node, depending on the type of 1027 equipment. The following client address forma should be 1028 supported: 1029 - IP addresses 1030 - NSAP addresses 1031 - ATM addresses 1033 Note that these addresses may be different to those used within the 1034 optical network, and will thus require conversion within the 1035 network. 1037 The use here of a range of naming schemes will require that the 1038 destination name be a variable length field. Thus, the destination 1039 name attribute must consist of a destination name type (i.e. one of 1040 the above address types), a destination name length, and the 1041 destination name itself. This attribute is not modifiable. 1043 - destination port index: if individual ports are not given unique 1044 addresses, then a port index is required to identify them. The 1045 destination port index used by a connection may be assigned by 1046 either the destination user, or by the network. This attribute is 1047 not modifiable. 1049 - destination channel (wavelength) identifier: when the network or 1050 end system allows multiplexing or switching at a finer granularity 1051 below the port level, the channel identifier is used to refer to 1052 specific channels below the port level. The destination channel 1053 identifier may be assigned by either the destination user or the 1054 network. When not applicable (i.e. no sub-port index), this 1055 attribute is given a null value. This attribute is required, for 1056 example, for channelized SONET/SDH interfaces. This attribute is 1057 not modifiable. 1059 - destination sub-channel identifier: a further level of destination 1060 multiplexing. This attribute is not modifiable. 1062 - source name: the name used to identify the node from which the 1063 connection is to be established. The same addressing schemes will 1064 be supported as for the destination name. Thus, the source 1065 address consists of a naming type, a name length and a variable 1066 length name. This attribute is not modifiable. 1068 - source port index: similar to destination port index. This 1069 attribute is not modifiable. 1071 - source channel (wavelength) identifier: similar to destination 1072 channel identifier. The source channel identifier may be assigned 1073 by either the source user or the network. This attribute is not 1074 modifiable. 1076 - source sub-channel identifier: similar to destination sub-channel 1077 identifier. This attribute will be included in UNI 1.0 and is not 1078 modifiable. 1080 - third party (proxy) attributes: third party or proxy signaling is 1081 essential in scenarios where an entity other than the equipment 1082 directly connected to the ONE over a user interface signals to the 1083 ONE in order to establish/modify/query/tear down a connection, on 1084 behalf of the client equipment. The third party/proxy could be a 1085 network entity (e.g., within the management plane of the network). 1086 Attributes describing the third party that initiates a connection 1087 action. These attributes would include the third party address 1088 and identifier (ID). In many cases the third party signaling is 1089 not used, and this field would then be null. Similarly, the 1090 default is null. However, there may be situations in which a 1091 separate control plane server is initiating the request on behalf 1092 of the source. This attribute requires further definition. 1094 3.3.2 Connection characteristic attributes 1096 The next group of attributes relate to the physical and transmission 1097 characteristics of a connection. 1098 - framing: the framing used on the connection is specified using two 1099 parameters, namely framing type and framing specific attributes: 1100 - framing type: the line protocol carried on the connection. The 1101 following framing types should be supported: 1102 - SONET T1.105 1103 - SDH G.707 1104 - Ethernet IEEE 802.3.x 1105 - Digital wrapper G.709 1106 - PDH 1107 - Transparent (wavelength service) 1109 - OH termination type: this field is framing specific. For SONET and 1110 SDH framing this field specifies to what degree the framing 1111 overhead bytes are terminated. The following values are to be 1112 supported for UNI 1.0 and they are consistent with ITU 1113 definitions: 1114 - RS: signal without termination of any OH. 1115 - MS: signal with termination of RSOH (section OH) possible 1116 - VC: signal with termination of RSOH (section OH), MSOH (line 1117 OH), and TCM OH possible 1119 Specific values for this field will be defined for each framing type 1120 if applicable. 1122 - bandwidth: this attribute is also correlated to framing type. Its 1123 values will be consistent with the allowable values within the 1124 selected framing type. For SONET this field will be used to 1125 indicate the bandwidth of the connection in terms of multiples of 1126 STS-1 (and VTx, if applicable), to allow for virtual 1127 concatenation. For SDH this field will be used to indicate the 1128 bandwidth of the connection in terms of multiples of VC-4s/STM-1s 1129 (and VC-3, VC-12, VC-11 if applicable), and should allow for 1130 virtual concatenation. For Ethernet, the values are in multiples 1131 of Mb/s, so that Gigabit Ethernet is represented as 1000, whilst 1132 10GbE is represented as 10000. 1134 - directionality: this attribute will indicate whether the 1135 connection is uni-directional or bi-directional. SONET, SDH and 1136 Ethernet are defined as bi-directional signals. However, it should 1137 be considered for future technologies. 1139 For reference and comparison with the above framing specifications, 1140 the T1 and ITU-T defined descriptors for SONET/SDH are given in the 1141 table 1: 1143 - priority, protection and restoration: priority, protection and 1144 restoration will be represented by two attributes: 1146 - service type: specifies a class of service. A carrier may specify 1147 a range of different classes of service (e.g. gold, silver, 1148 bronze) with predefined characteristics (e.g. restoration plans). 1149 The pre-defined service types correspond to different types of 1150 restoration (e.g. no restoration, 1+1 protection), connection set- 1151 up and hold priorities, reversion strategies for the connection 1152 after failures have been repaired, and retention strategies. This 1153 attribute and it may be non-destructively modifiable. 1155 - drop side protection: refers to the protection between the user 1156 network elements and the optical network. Two different fields 1157 will be used to specify protection used at the two ends of the 1158 connection (i.e. different protection schemes can be used at both 1159 ends of the connection). 1161 - The drop side protection schemes available are: 1162 0:1 (unprotected) 1163 1:N 1164 M:N 1165 1+1 1166 Dual-homing drop side protection requires further investigation. 1168 - optical layer parameters: these parameters are of interest in all- 1169 optical networks, and include optical SNR and jitter. These 1170 parameters will not be necessary where SONET/SDH framing is 1171 enforced. 1173 3.3.3 Routing attributes 1175 - routing relationships among connections: various relationships may 1176 be defined between connections. For example, a user may request 1177 that multiple connections be diversely routed, that multiple 1178 connections be routed along the same shared physical route, that 1179 multiple connections be bundled together and treated as a single 1180 entity with a common set of attributes (although potentially 1181 different / diverse routing), or that a given connection be routed 1182 on the same path as an existing connection. 1184 Two connections are diverse if they have no Shared Risk Link Groups 1185 (SRLG) in common. Diverse routing is frequently a requirement of 1186 sophisticated enterprise networks whose availability objectives may 1187 require that no single failure isolate a node or disconnect the 1188 network, for example. The diversity requirement for such a network 1189 is best expressed by a matrix: If there are N connections involved 1190 between the same end points, then A[j,k] specifies whether 1191 connections j and k must be diverse. 1193 Connections may initially be requested with the intention of adding 1194 a diversely routed connection at a future point in time. This 1196 allows requests to be individually handled whilst still providing 1197 diversity at a later date without service interruption. The routing 1198 of the initial connection would then take into account the ability 1199 of providing diversely routed connections. Additionally, the extent 1200 to which diversity is provided in an optical internetwork is an 1201 important issue to be considered. Finally, the definition of how 1202 multiple connections may be bundled together is of interest to the 1203 carriers. 1205 UNI should allow simple requests for diverse connections and for 1206 connections routed on common routes. Thus, this field consists of 1207 two values - a value defining the relationship between this 1208 connection and others (node diverse, link diverse, SRLG diverse, 1209 shared or no relationship) and a list of connection's to which the 1210 connection associated with this attribute is to be diversely routed, 1211 or a single connection to which the connection associated with this 1212 attribute is to have a shared (common) route. These connections are 1213 specified using connection identifiers. This attribute is not 1214 modifiable. 1216 More complicated diversity constraints may also be included in UNI 1217 specifications as follows. 1218 - user constraints: user constraints may have to be propagated 1219 across the UNI - particularly in all-optical networks without 1220 wavelength conversion available between the user and the network. 1221 In particular, information may have to be conveyed regarding the 1222 set of wavelengths accessible from the user and whether the user 1223 can re-tune its wavelengths in the face of a failure within the 1224 network. 1226 The following attributes may also be considered for inclusion in the 1227 UNI specifications. 1228 - policy object: potentially required as input for administrative 1229 criteria used to decide whether a service request should be 1230 granted by the optical internetwork [10]. This field may be used 1231 to transport information such as credit card or account number 1232 details, which may be required for service validation. 1233 - delay: delay will not be included in the UNI specification, and 1234 will instead be defined from a carrier perspective only. 1236 3.4 Interface Types 1238 The interface type is determined by the specific technology, framing 1239 and bit rate of the physical interface between the ONE and the user 1240 edge device (UED). Multiple interface types need to be supported by 1241 UNI: 1243 All the physical interfaces below that are implemented in the ONE 1244 shall be supported by the signaling protocol. 1245 - SDH 1246 - SONET 1247 - 1 Gb Ethernet, 10 Gb Ethernet (WAN mode) 1249 - 10 Gb Ethernet (LAN mode) 1250 - Digital wrapper (G.709) 1251 - PDH 1252 - Transparent optical 1254 The connection types supported by UNI shall be consistent with the 1255 service granularity and interface types supported by the ONE. 1257 Other interface types to be considered for later versions: 1259 - Selectable bit rate: Selectable bit rate support is needed for 1260 provisionable interfaces such as are found in metro products. For 1261 example an OC-12/STM-4 line card may also be used for an OC-3/STM- 1262 1 signal. For this case the user NE needs to signal to the network 1263 which interface rate should be applied to the new connection, 1264 - Composite types: Composite interface types are not currently 1265 available, but they are mentioned in this document for future 1266 extensibility. For example, a composite 40 GB/s interface type may 1267 contain a mix of OC-192/STM-64 and 10Gb/s Ethernet, 1268 - Protocol independent optical channels, 1270 In addition, sub-rate extensions of UNI (UNI-SR) will be based on 1271 lower bandwidth interfaces going down to potentially DS1/E1 formats. 1272 Subrate extensions of UNI shall support sub-rate interfaces down to 1273 VT1.5/TU-l1, or DS1/E1 signals. Therefore physical interfaces may 1274 need to be supported on the network device. 1276 3.5 Addressing Schemes 1277 While, IP-centric services are considered by many as one of the 1278 drivers for optical network services, it is also widely recognized 1279 that the optical network will be used in support of a large array of 1280 both data and voice services. In order to achieve real-time 1281 provisioning for all services supported by the optical network while 1282 minimizing OSS development by carriers, it is essential for the 1283 network to support a UNI definition that does not exclude non-IP 1284 services. For this reason, multiple naming schemes should be 1285 supported to allow network intelligence to grow towards the edges. 1287 In this section addressing refers to optical layer addressing and it 1288 is an identifier required for routing and signaling protocol within 1289 the optical network. Identification used by other logical entities 1290 outside the optical network control plane (such as higher layer 1291 services addressing schemes or a management plane addressing scheme) 1292 may be used as naming schemes by the optical network. Recognizing 1293 that multiple types of higher layer services need to be supported by 1294 the optical network, multiple user edge device naming schemes must 1295 supported, including at the minimum IP and NSAP naming schemes. 1297 The following section discusses the naming schemes that have been 1298 deemed as relevant for the carriers. 1300 3.5.1 Physical Entity Naming 1302 For each connection, (independent of which service it supports) the 1303 following information is tracked (by the control plane and/or the 1304 management plane): 1305 - Access/Ingress facility 1306 - Point of entry into the CO: CO/NE Id/bay/shelf/slot/port/timeslot 1307 or wavelength, 1308 - Point of exit off CO: CO/NE Id/bay/shelf/slot/port/timeslot or 1309 wavelength, 1310 - Inter-office facility: facility Id/wavelength/timeslot, 1311 - Intra-office wiring detail 1312 - Egress/Access facility 1314 Carrier Network Elements identify individual ports by their location 1315 using a scheme based on "CO/NE/bay/shelf/slot/port" addressing 1316 schema. Similarly, facilities are identified by route 1317 "id/fiber/wavelength/timeslot". 1319 - An optical path crossing the network is represented as a 1320 collection of NE resources and facilities strung together, 1321 - The addressing method described above is generally called physical 1322 entity addressing. 1323 - Physical entity addressing is widely used by US carriers to track 1324 facility assignments and for private line provisioning and 1325 maintenance. Service layer addressing schemes are often translated 1326 into physical layer addressing for maintenance, testing and 1327 assignment verification. 1329 Mapping of Physical Entity addressing to Optical Network addressing 1330 shall be supported. 1332 3.5.2 IP Naming 1334 While there is a concerted effort to ensure that the optical network 1335 will support a wide array of transport services, it is first and 1336 foremost geared towards data-centric transport. As such, the first 1337 users to be supported by UNI will be routers. To realize fast 1338 provisioning and bandwidth on demand services in response to router 1339 requests, it is essential to support IP naming. 1341 Mapping of higher layer user IP naming to Optical Network Addressing 1342 shall be supported. 1344 3.5.3 NSAP Naming 1346 European carriers use NSAP naming for private lines and many US data 1347 centric applications, including ATM-based services also use NSAP 1348 addresses. As such it is important that NSAP naming should be 1349 supported. Mapping of higher layer NSAP naming to Optical Network 1350 shall be supported. 1352 3.6 Directory Services and Address Translation 1354 The routing, signaling and provisioning in the optical domain uses 1355 the optical network address. To handle user's optical connection 1356 requests, it's convenient to the requester (either UED for UNI or 1357 operator for management interface) to use the user naming for the 1358 specification of the service request. Address resolution requires 1359 the network to provide directory service for the translation of 1360 multiple user network naming to the optical network address in a way 1361 totally transparent to the connection provisioning. 1363 - Directory Services shall be supported to enable user or operator 1364 to query the optical network for the optical network address of a 1365 specified user. 1366 - Address resolution and translation between various user edge 1367 device name and corresponding optical network address shall be 1368 supported. 1369 - UNI shall use the user naming schemes for connection request. 1371 3.7 Access Methods for Services 1373 User network can be connected to the carrier's optical network 1374 either via directly fiber links or via other indirect access 1375 methods. The following list some of the access methods that shall be 1376 supported: 1377 - Cross-office access (User NE co-located with ONE) 1378 In this scenario each user NE has one or more cross-office 1379 connections to the ONE. Some of these access connections may be in 1380 use, while others may be idle pending a new connection request. 1381 - Remote access 1382 In this scenario each user NE has inter-location connections to 1383 the ONE over multiple fiber pairs or via a DWDM system. Some of 1384 these connections may be in use, while others may be idle pending 1385 a new connection request. 1386 - Third-party access. In this scenario each user NE is connected to 1387 the third party's ONE via cross-office or remote access. The user 1388 requests additional connections from the third party. There are 1389 potential 3 scenarios at this point: 1390 - The third party either has leased lines from one or more 1391 carriers 1392 - The third party starts negotiating for new connections on behalf 1393 of the user 1394 - The third party opens a new connection into an agreed upon (or 1395 negotiated carrier) and the user negotiates the new connection 1396 directly with the carrier. 1398 UNI shall support the ability of the user edge device to select 1399 which ONE entity it will signal to. 1401 3.8 Transparent Services Features and Constraints 1403 The transparent service and bit-stream service are two services of 1404 interest to the carriers for certain future applications. 1406 3.8.1 Transparent Optical Connections 1408 Transparent Optical connections are not aware of individual bit 1409 stream framing. A wavelength of a given bandwidth is allocated to 1410 the service. Framing OH is not terminated/monitored (e.g., if a 1411 proprietary protocol is used). Only optical parameters are supported 1412 by the network in this case. The optical path may have limitations 1413 on distance, depending on the technology deployed by the network 1414 operator. While important, it is generally considered that 1415 transparent optical services are not currently understood well 1416 enough to ensure appropriate standards support for them. 1418 3.8.2 Levels of Transparency for Bitstream Connections 1420 Bitstream connections are framing aware - the exact signal framing 1421 is known or needs to be negotiated between network operator and 1422 user. However, there may be multiple levels of transparency for 1423 individual framing types. The following levels have to be considered 1424 for optical connections: 1425 - SONET Line and section OH (SDH multiplex and regenerator section 1426 OH) are normally terminated and a large set of parameters can be 1427 monitored by the network. 1428 - Line and section OH are carried transparently 1429 - Non-SONET/SDH transparent bit stream 1431 Multiple levels of transparent services shall be supported: 1432 - SONET/SDH Line and Section terminating. 1433 - SONET/SDH Section terminating with Line transparency. 1434 - SONET/SDH with Line and Section transparency. 1435 - Non-SONET/SDH transparent bit-streams. 1437 3.9 Other Service Parameters and requirements 1439 Source/destination sub-port index support shall include support of 1440 multiple wavelengths on a single port for those situations where 1441 multiple wavelengths are multiplexed into the same port. 1443 The ability to have scheduled connections is needed in order to: 1444 - offer time of day network reconfiguration. 1445 - reserve capacity for availability at some time in the future 1446 without allocating it immediately. 1447 - support network reconfigurations involving dependencies (e.g., 1448 roll A to make room for B). 1449 - schedule maintenance activities without disrupting traffic 1451 Connection scheduling must be supported including support of 1452 recurring connections. The following recurring service flavors have 1453 been identified: 1454 - No guarantees - At the scheduled time a connection request is made 1455 which may succeed or fail depending on resource availability at 1456 that time. This is simple, but not a satisfactory solution. 1457 - "Expensive" guarantees: The resources are allocated and held at 1458 the time of request, so if the original request succeeds then the 1459 scheduled service is guaranteed because no one else can use the 1460 resource in the interim. This is relatively simple, but then the 1462 question arises regarding bothering with the schedule. As the 1463 resources are being dedicated from the time of the request, it 1464 would be simpler just to complete the entire connection at that 1465 time and hold it. 1466 - "Complex" guarantees: Every resource maintains a schedule of its 1467 future allocations. At the time of the request the availability 1468 at the scheduled time is determined, and reserved if it is 1469 available. This is the ideal scheduling application, but current 1470 state of control plane development does not support it. 1472 Signaling for connection scheduling should be supported. At a 1473 minimum, expensive guarantees shall be supported by the control plan 1474 of ONE. However, it is desirable that complex guarantees be 1475 supported. 1477 3.10 Protection/Restoration Options 1479 We use "service level" to describe priority related characteristics 1480 of connections, such as holding priority, set-up priority, or 1481 restoration priority. The intent currently is to allow each carrier 1482 to define the actual service level in terms of priority, protection, 1483 and restoration options. Therefore, mapping of individual service 1484 levels to a specific set of priorities will be determined by 1485 individual carriers. 1487 Multiple service level options shall be supported and the user shall 1488 have the option of selecting over the UNI a service level for an 1489 individual connection. However, in order for the network to support 1490 multiple grades of restoration, the control plane must identify, 1491 assign, and track multiple protection and restoration options. 1493 Protection is a collection of proactive techniques meant to 1494 rehabilitate failed connections. Protection assumes redundancy 1495 network resources (e.g., of ONE fabric, of physical interfaces on 1496 the ONEs, and of associated facilities) and is generally supported 1497 by automated switching within terminating line cards. 1499 Restoration is a collection of reactive techniques used to 1500 rehabilitate failed connections. Restoration supports individual 1501 connections, and it may recover those connections end-to-end. 1502 Allocation of specific restoration facilities may be pre-determined, 1503 (such as building alternate restoration maps within ONEs) or 1504 dynamically calculated in a "best-effort" manner as network failures 1505 occur. 1507 While potentially not impacting the UNI itself, the following 1508 requirements are considered essential within the network. 1509 Multiple protection options are needed in the network. The following 1510 protection schemes should be considered for ONEs inter-connected 1511 within the network: 1512 - Dedicated protection (e.g., 1+1, 1:1) 1514 - Shared protection (e.g., 1:N). This allows the network to ensure 1515 high quality service for customers, while still managing its 1516 physical resources efficiently. 1517 - Unprotected 1518 - Pre-emptable 1520 Multiple types of facilities available for restoration are needed 1521 within the network. The following options should be considered for 1522 allocation of facilities to support restoration of failed 1523 connections: 1524 - Dedicated restoration capacity 1525 - Shared restoration capacity. This allows the network to ensure 1526 high quality service for customers, while still managing its 1527 physical resources efficiently. 1528 - Un-restorable 1529 - Pre-empteable 1531 Individual carriers will select appropriate options for protection 1532 and/or restoration in support of their specific network plans. 1534 3.11 Drop Side Protection 1536 Drop side protection refers to the protection schemes available on 1537 the interface between the ONE and the user edge device. There are 1538 several drop side protection alternatives used in today's network: 1539 1+1, 1:N, or unprotected. 1540 - It is desirable for ONEs to support multiple options for drop side 1541 protection. 1542 - It is also highly desirable that the protection option be 1543 configurable via software commands (as opposed to needing hardware 1544 reconfigurations) to change the protection mode. 1546 4. Network Control Functions and Architecture 1548 This section discusses the optical network control plane 1549 requirements. 1551 4.1 Control Plane Functions 1553 The control plane related to the UNI usually includes: 1554 - Signaling 1555 - Routing 1556 - Resource and service discovery 1558 Signaling is the process of control message exchange using a well- 1559 defined signaling protocol to achieve communication between the 1560 controlling functional entities connected through a specified 1561 communication channels. It is often used for dynamic connection set- 1562 up across a network. 1564 Routing is a distributed networking process within the network for 1565 dynamic dissemination and propagation of the network information 1566 among all the routing entities based on a well-defined routing 1568 protocol. It enables the routing entity to compute the best path 1569 from one point to another. 1571 Resource and service discovery is the automatic process between the 1572 connected network devices using a resource/service discovery 1573 protocol to determine the available services across UNI and identify 1574 connection entities and their state information. 1576 The general requirements for the control plane functions to support 1577 optical networking functions include: 1578 - The control plane must have the capability to establish, teardown 1579 and maintain the end-to-end connection across the optical domain 1580 network in real-time manner. 1581 - The control plane must have the capability to configure and 1582 unconfigure cross connetion table of the ONE to enable set up of 1583 static optional connection similar to the ATM PVC. 1584 - The control plane must have the capability to support traffic- 1585 engineering requirements including resource discovery and 1586 dissemination, constraint-based routing and path computation. 1587 - The control plane must have the capability to support various 1588 protection and restoration schemes for the optical channel 1589 establishment. 1591 4.2 Control Plane Access 1593 Control functions need to be accessible via the following 1594 interfaces: network management system interface, network element 1595 management plane interface, UNI and NNI. That is to say, the access 1596 to the control plane functions can be via one of the following 1597 paths: 1598 - UNI 1599 - NNI 1600 - Element Management System/Network Element Interface (EMS/NEI) 1602 Different access configurations may be used depending on the 1603 specific applications. For example, access via management interface 1604 is for static service provisioning and access via UNI is for dynamic 1605 or bandwidth-on-demand service provisioning. 1607 4.3 Signaling Channels 1609 A signaling channel is the communication path for transporting UNI 1610 signaling messages between the UNI entity on the user side (UNI-C) 1611 and the UNI entity on the network side (UNI-N). 1613 4.3.1 In-band and Out-of-Band Signaling 1615 There are two different types of the signaling methods depending on 1616 the way the signaling channel is constructed: 1617 - In-Band Signaling: The signaling messages are carried over a 1618 logical communication channel embedded in the data-carrying 1619 optical link or channel between the UNI-C and UNI-N residing 1620 devices. For example, using the overhead bytes in SONET data 1622 framing as a logical communication channel falls into the in-band 1623 signaling methods. 1624 - Out-of-Band Signaling: The signaling messages are carried over a 1625 dedicated communication channel or fiber path separate from the 1626 optical data-bearing channels. For example, dedicated optical 1627 fiber link or wavelength channel, or communication path via 1628 separate and independent IP-based network infrastructure between 1629 the UNI-C and UNI-N residing devices are the methods of out-of- 1630 band signaling. 1632 When there are multiple links (optical fibers or multiple wavelength 1633 channels) between a pair of user edge device and connected network 1634 edge device, failure of the signaling channel will have much bigger 1635 impact on the service availability than the single case. It is 1636 therefore recommended to support certain level of protection of the 1637 signaling channel. 1639 In-band signaling should be supported, where possible. Out-of-band 1640 signaling shall be supported. Implementation of the out-of-band 1641 signaling and management interface as a minimum shall include 1642 Ethernet (including 10MbE, 100MbE and 1GbE) technology. 1644 4.3.2 Third-party Signaling 1646 Third party (proxy) signaling is a special signaling scenario and is 1647 useful to support users unable to signal to the optical network via 1648 a direct communication channel. In this situation a third party 1649 systems containing the UNI-C entity will initiate and process the 1650 information exchange on behalf of the user device and the network 1651 device. The UNI-C and UNI-N entities in this case reside outside of 1652 the user and network devices in separate signaling systems. 1653 It is highly desirable to have support of third party (proxy) 1654 signaling. 1656 4.4 Routing Functions 1658 To support UNI functions, the routing supports discovery and 1659 propagation of reachability and topological information within 1660 optical networks, between different optical networks, and possibly 1661 between optical networks and user networks. It is responsible for 1662 route calculations and selection during the dynamic connection 1663 provisioning. 1665 Carrier service operators are very sensitive to the routing policy 1666 that determines how the routing functions are performed and to what 1667 extent the routing information should be exchanged between networks 1668 or between the optical network and user network. 1670 4.4.1 Routing Model 1672 Routing models define how the routing information in the optical 1673 network domain and the user data network domain are disseminated and 1674 how the routing information is exchanged between the domains. 1676 - Both the optical network and user data network, each runs its own 1677 version of routing protocols, which could be identical or totally 1678 different. 1679 - At UNI and NNI interface, a policy-based configurable mechanism 1680 should be available to control routing information exchange across 1681 the UNI/NNI interface. 1683 A routing protocol and a signaling mechanism are required for the 1684 optical domain to automatically provision a connection across the 1685 optical network domain. The demarcation line (UNI) should support 1686 the separation of control plane between the optical network and the 1687 user networks. 1689 There are three different routing models [7]: 1690 - Peer Model: User network routing protocol has a peer relation with 1691 the optical network routing protocol and there is exchange of 1692 routing information between two routing domains at UNI. 1693 - Overlay Model: User network routing protocol is running 1694 independently of the optical network routing protocol and there is 1695 no exchange of routing information at UNI. The overlay model must 1696 be supported over public UNI interfaces. 1697 - Augmented Model: The optical network propagates the user network 1698 reachability information among all the user networks, which are 1699 exchanged at UNI. However the topology information of the optical 1700 network is filtered out at UNI to the users and the reachability 1701 information propagation may be constrained. For example, only the 1702 users of the same group (e.g. OVPN) are allowed to exchange the 1703 reachability information. 1705 4.4.1 Routing Protocols 1707 In the overlay routing models, two independent routing protocols are 1708 run within the domain of the optical networks and the user network, 1709 but the two protocols could be the same. 1711 In the augmented routing models, two independent routing protocols 1712 are run within the domain of the optical networks and the user 1713 network, certain level of compatibility is required to support 1714 controlled propagation 1716 In the peer model, there are several possible scenarios: 1717 - A single instance of routing protocol runs across both the optical 1718 network and the user network as a single routing domain. 1719 - Different instances of routing protocols (could be the same 1720 protocol) are running in both optical network and its user 1721 networks. Routing information exchange occurs across UNIs. This 1722 provides the flexibility for each network to use its own routing 1723 protocol. 1725 4.4.3 Routing Constraints 1727 Routing constraints in the context of this document are the 1728 conditions and restrictions imposed by the network topology, 1730 technology administrative policy and special requirements when 1731 routing an optical path across an optical network. 1733 4.4.3.1 Reachability Routing Constraints 1735 The ability to provision a network optical path between two user 1736 edge devices based on user network address is a desired feature, 1737 which requires the knowledge of the destination user network 1738 address. However the members of different user groups may not 1739 allowed to set up direct optical connections across the optical 1740 network and it's up to the network control plane to support 1741 configuration, control and enforce reachability propagation among 1742 the user networks. Therefore, 1743 - It is required for the routing control system to automatically 1744 generate and maintain a directory service with the help of auto 1745 end-system discovery. 1746 - It is required to have configurable capability at the UNI to 1747 control the exchange of routing information. 1748 - Only reachability information shall be advertised into the optical 1749 network from the user network and the optical network shall be 1750 able to propagate the user reachability information within the 1751 optical core and advertise it into each user network. Topology 1752 information of the optical network in general shall NOT be 1753 advertised to the user networks. 1754 - It is required that only the users that belong to the same user 1755 group can exchange reachability information. 1757 4.4.3.2 Diverse Routing Constraints 1759 The ability to route service paths diversely is a highly desirable 1760 feature. Diverse routing is one of the connection parameters and is 1761 specified at the time of the connection creation. The following 1762 provides a basic set of requirements for the diverse routing 1763 support. Some discussion details can be found in the [6] 1765 - Diversity compromises between two links being used for routing 1766 should be defined in terms of Shared Risk Link, a group of links 1767 which share some resource, such as a specific sequence of conduits 1768 or a specific office. A SRLG is a relationship between the links 1769 that should be characterized by two parameters: 1770 1. Type of Compromise: Examples would be shared fiber cable, shared 1771 conduit, shared ROW, shared link on an optical ring, shared 1772 office - no power sharing, etc.) 1773 2. Extent of Compromise: For compromised outside plant, this would 1774 be the length of the sharing. 1775 - The control plane routing algorithms shall be able to route a 1776 single demand diversely from N previously routed demands, where 1777 diversity would be defined to mean that no more than K demands 1778 (previously routed plus the new demand) should fail in the event 1779 of a single covered failure. Additional diversity routing 1780 capabilities, including the ability to do diversity constrained 1781 routing of multiple circuits simultaneously, is needed. 1783 4.4.3.3 Other Routing Constraints 1785 There are other constraints that affect the routability of the 1786 connections across the optical network due to certain architectural 1787 functions in the network. Some of them are listed below: 1788 - Adaptation: These are the functions done at the edges of the 1789 subnetwork, which transform the incoming optical channel into the 1790 physical wavelength to be transported through the subnetwork. 1791 - Connectivity: This defines which pairs of edge Adaptation 1792 functions can be interconnected through the subnetwork. 1793 - Multiplexing: Either electrical or optical TDM may be used to 1794 combine the input channels into a single wavelength. This is done 1795 to increase effective capacity: 1796 - Channel Grouping: In this technique, groups of k (e.g., 4) 1797 wavelengths are tightly spaced, with wider spacing between groups. 1798 Wavelength groups are then managed as a group within the system 1799 and must be added/dropped as a group 1800 - Laser Tunability: The lasers producing the long reach (LR) 1801 wavelengths may have a fixed frequency, may be tunable over a 1802 limited range, or be tunable over the entire range of wavelengths 1803 supported by the DWDM. 1805 The carrier group recommends the following routing constraints 1806 support: 1807 - Routing constrained by TDM and channel grouping shall be 1808 supported. For example, TDM and/or channel grouping by the 1809 adaptation function forces groups of input channels to be 1810 delivered together to the same distant adaptation function. 1811 - Routing constrained by system-specific constraints on adaptation 1812 connectivity shall be supported. For example, only adaptation 1813 functions whose lasers/receivers are tuned to compatible 1814 frequencies can be connected. 1815 - Management plane/EMS reconfiguration of system connectivity 1816 between adaptation functions shall be supported. Convergence time 1817 after a such a reconfiguration shall not exceed a preset number. 1819 4.4.3.4 Routing for OVPN 1821 For further study. 1823 4.5 Automatic Discovery Functions 1825 To enable dynamic and rapid provisioning of end-to-end service path 1826 across the optical network, two automatic discovery functions shall 1827 be provided, namely service discovery and end-system discovery. 1829 4.5.1 Service Discovery 1831 The service discovery is the process of information exchange between 1832 two directly connected end systems equipment: the user edge device 1833 and the network edge device. The objective is for network to obtain 1834 essential information about the end-system and thereby provide the 1835 information about available services to the end-system. 1837 Service discovery processes is defined by the type of information to 1838 be exchanged, the procedure that governs the exchange process and 1839 the communication mechanism to be used to realize the information 1840 exchange. 1842 The service discovery is key to facilitating interoperability, 1843 configuration automation and automatic service provisioning. 1845 4.5.2 End-System Discovery 1847 The end-System discovery is the process of information exchange 1848 between the edge ONE of the optical network and the user edge 1849 device. The objective is for each side to obtain essential 1850 information about the network element at the other side of the 1851 optical link and understand the link status and properties between 1852 them. 1854 The information exchanged in the end-system discovery process shall 1855 enable both network elements to recognize the existence and identity 1856 of each other, obtain functional information from each other. It 1857 should enable UNI to identify and verify each and every link between 1858 the network edge ONE and user edge devices in terms of port level 1859 connection, network level identifier and addresses, and their 1860 corresponding operational state. 1862 The end-system discovery shall support both end-system address 1863 registration and de-registration function. The registration shall 1864 associate the address and user group of the user edge device with 1865 the corresponding termination point address of the optical network. 1866 The list of essential information obtained in the discovery process 1867 shall be accessible from both network management interface and the 1868 network element management plane interface for troubleshooting 1869 purpose. 1871 The end-system discovery processes is defined by the type of 1872 information to be exchanged, the procedure that governs the exchange 1873 process and the communication mechanism to be used to realize the 1874 information exchange. 1876 The end-system discovery is key to facilitating interoperability, 1877 configuration automation and automatic service provisioning. 1879 4.5.3 Communication Mechanism 1881 The communication mechanism for the service and end-system discovery 1882 shall be selectable through configuration or through automatic 1883 negotiation. 1885 The communication mechanism for the service and end-system discovery 1886 is usually expected to shares the same communication mechanism for 1887 control signaling channel, but they can use two different 1889 communication channels. As with the signaling channel, the 1890 communication channel may be either in-band or out-of-band. 1892 5. Security Considerations 1894 Security issues is a very serious issues in developing the UNI 1895 function and protocols and must be carefully studied. This topic 1896 will be a separate study. 1898 6. Acknowledgments 1900 The authors would like to thank all the members of OIF Carrier Sub- 1901 Working Group for their constructive comments. We would like to 1902 thank Eve Varma for her useful and constructive comments. 1904 References: 1906 [1] Y. Xue and M. Lazer, "Carrier Optical Services Framework and 1907 Associated Requirements for UNI." OIF2000.155. 1909 [2] L. McAdams, Jennifer Yates, "User to Network Interface (UNI) 1910 Service Definition and Connection Attributes" OIF2000.061 1912 [3] ITU-T Draft New Recommendation G.709, "Network Node Interface 1913 for the Optical Transport Network", April 2000. 1915 [4] ITU-T Recommendation G.872, "Architecture of Optical 1916 Transport Networks", 1999. 1918 [5] Draft of ITU-T Rec. G.ason, "Architecture for the Automatic 1919 Switched Optical Network" (ASON), February 2000. 1921 [6] M. Lazer, J. Strand, "Some Routing Constraints", OIF2000.109 1923 [7] Bala Rajagopalan, James Luciani, Daniel Awduche, Brad Cain, 1924 Bilel Jamoussi "IP over Optical Networks: A Framework", draft-many- 1925 ip-optical-framework-01.txt. 1927 [8] Demitrios Pendarakis, "Deployment Considerations for the User 1928 to Network Interface (UNI), OIF2000.096 1930 Authors' Addresses: 1932 Yong Xue 1933 UUNET/WorldCom 1934 22001 Loudoun County Parkway 1935 Ashburn, VA 20147 1936 Phone: +1 (703) 886-5358 1937 Email: yxue@uu.net 1939 Daniel Awduche 1941 UUNET/WorldCom 1942 22001 Loudoun County Parkway 1943 Ashburn, VA 20147 1944 Phone: +1 (703) 886-5277 1945 Email: awduche@uu.net 1947 Monica A. Lazer 1948 AT&T 1949 900 Route 202/206 1950 Bedminster, NJ 07921 1951 Phone: (908) 234 8462 1952 Email: mlazer@att.com 1954 John Strand 1955 AT&T Labs 1956 100 Schulz Dr., Rm 4-212 1957 Red Bank, NJ 07701, USA 1958 Phone: +1 (732) 345-3255 1959 Email: jls@att.com 1961 Jennifer Yates 1962 AT&T Labs 1963 180 Park Avenue, Rm B159 1964 Florham Park, NJ 07932 1965 Phone: 973-360-7036 1966 Email: jyates@research.att.com 1968 Larry McAdams 1969 Cisco Systems 1970 170 West Tasman Dr. 1971 San Jose, CA 95134-1706 1972 Phone: 408-525-4628 1973 Email: lmcadams@cisco.com 1975 Cable & Wireless Global 1976 11700 Plaza America Drive 1977 Reston, VA 20191 1978 Phone: 703-292-2022 1979 Email: olga.aparicio@cwusa.com 1981 Roderick Dottin 1982 Cable & Wireless Global 1983 11700 Plaza America Drive 1984 Reston, VA 20191 1985 Phone: 703-292-2108 1986 Email: roderick.dottin@cwusa.com 1988 Rahul Aggarwal 1989 Redback Networks 1990 350 Holger Way 1991 San Jose, CA 95134 USA 1993 Phone: 408-571-5378 1994 Email: rahul@redback.com