Internet Draft MPLS Working Group Monica Lazer, AT&T Internet Draft Curtis Brownmiller, Worlcom Expiration Date: May 2001 Zhi-Wei Lin, Lucent Vijaya Poudyal, Telcordia Philip Walch, TyCom Mark Jones, Sprint Olivier Duroyon, Alcatel Jen-Wei Kuo, Fujitsu Yang Cao, Sycamore Hirokazu Ishimatsu, Japan Telecom Yong Xue, UUNET/Worldcom November 2000 Requirements on the ASON UNI draft-lin-mpls-ipo-ason-uni-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Work already done on the automatic switched optical network (ASON) has identified several requirements and architectural features. In particular several interfaces have been identified, however there are no detailed requirements for these interfaces. This document presents our understanding of requirements from the point of view of what an ASON customer can be expected to do with ASON. These are Lin, et al. 1 Requirements on the ASON UNI November, 2000 mainly requirements at the Client Application Programming Interface (API). Note that the Client API is the logical interface between a network client (user domain) and the network server (service provider domain). Lin, et al. Expires May 2001 2 Requirements on the ASON UNI November, 2000 Table of Contents 1. Introduction....................................................4 2. Terminology.....................................................5 3. Business/Commercial Models......................................6 3.1 ISP owning all layer 1 infrastructure..........................7 3.2 ISP owning partial or leasing layer 1 infrastructure...........7 3.3 Retailer or wholesaler for multi-services......................7 3.4 Carriers carrier, or bandwidth broker..........................8 4. ASON 'Dial-up' Service Requirements.............................8 4.1 Connection Operations..........................................9 4.2 Connection Resilience.........................................10 4.3 Signaling Network Resilience..................................11 4.4 Connection Parameters.........................................11 4.5 Scheduled Connection..........................................12 4.6 ASON Service Level Agreements.................................12 4.7 Naming and Addressing.........................................14 5. Set-up of ASON Network.........................................18 5.1 Operations Phases.............................................18 5.2 Connection Phases.............................................19 5.2.1 Set-up (Create) Connection..................................19 5.2.2 Modify Connection...........................................21 5.2.3 Release (Delete) Connection.................................21 5.2.4 Query Connection............................................22 Lin, et al. Expires May 2001 3 Requirements on the ASON UNI November, 2000 1. Introduction Work already done on the automatic switched optical network (ASON) has identified several requirements and architectural features. In particular several interfaces have been identified, however there are no detailed requirements for these interfaces. This document presents our understanding of requirements from the point of view of what an ASON customer can be expected to do with ASON. These are mainly requirements at the Client Application Programming Interface (API). Note that the Client API is the logical interface between a network client (user domain) and the network server (service provider domain). Requirements on the ASON NNI are out of the scope of this document. The contribution limits itself to customer control aspects, and makes no statements about what may or may not be supported using conventional provisioning protocols. Several high level aspects of the ASON Client API requirements need to be highlighted: ? Several aspects of the ASON network related to the use of naming and addressing are discussed in more detail in later sections of this document. However, it should be noted that the name and address schemes used in the ASON are orthogonal to the signaling or routing protocol, and should be viewed as independently defined, e.g., addressing is used in support of routing and specific implementations of routing protocol. Two perspectives may be applied to the name and address: that of layer separation and that of domain separation. Layer separation refers to the independence of the client layer name from the server layer name, while domain separation refers to the independence of user domain name from the service provider domain name. Requirements for the name and address will be discussed in greater detail in later sections. ? In discussing the naming and addressing for the ASON network, two aspects need to be considered: that of the layer network naming (client/server name relationship) and that of the administrative domain naming (user/service provider name relationship). ? There are multiple methods to provide signaling for ASON connection set-up. In this document, we assume that ASON signaling may be initiated by user signaling agents or by third party signaling agents (proxy signaling agents). It must be possible for both participants and third parties to set-up calls, and it must be possible to have a control plane that is not associated with the connection being set-up. This contribution assumes that wherever user signaling agents are used, third party signaling agents may also be applied. Lin, et al. Expires May 2001 4 Requirements on the ASON UNI November, 2000 2. Terminology For the purposes of discussion, the following terms are used in this document. Note that there are two terms used in the context of this document, that relate to the IETF and the OIF terminology and that relate to the ITU-T terminology (in parenthesis). This document attempts to map these terminologies, with a note that in many cases the terms do not map directly to each other, and only provide a loose correlation. Definitions given below are those associated with the current understanding of the OIF definitions. An alignment of these terminology with that of the ITU terminology will be needed: ? Client link connection (lightpath) _ Entity formed by the two connection points (IP-capable end-points), which may be realized as a trail across the service provider network. ? Connection request (lightpath request) _ A request issued by either (a) user signaling agent, or (b) third party signaling agent, on behalf of the user network element. This can use, e.g., extended RSVP or CR-LDP. ? Optical NNI (O-NNI) _ Provides the logical transport interface for interconnecting network elements within a single domain. ? Optical UNI (O-UNI) _ Provides the logical transport interface for interconnecting network elements between two logical domains. ? Service provider domain - The collection of hosts, applications, and interconnecting network(s) that are managed by the service provider(s). ? Service provider network element (boundary ONE) _ NE within the service provider's domain that is providing connection to a NE within the user's domain. ? Service provider signaling agent (ONE-Controller, ONE-C) _ Device processing any kind of signaling channel messages and controls the connection request set-up. The signaling agent may be integrated with the service provider NE or as a separate device that remotely control one or more service provider NEs, i.e., no requirement is placed regarding the packaging of the signaling agent. ? Signaling NNI (S-NNI) _ Provides the logical signaling interface for interconnecting network elements within a single domain. The S-NNI does not place requirements on methods for transport of the signaling channel. ? Signaling UNI (S-UNI) _ Provides the logical signaling interface for interconnecting network elements between two logical domains. The S-UNI does not place requirements on methods for transport of the signaling channel (i.e., in-band or out-of-band). ? User domain - The collection of hosts, applications, and interconnecting network(s) that are managed by the user(s). Lin, et al. Expires May 2001 5 Requirements on the ASON UNI November, 2000 ? User domain connection point (IP-capable end-point) _ The connection point within the user's domain involved with creating a link connection across the service provider network (Boundary router's physical ports, interconnecting with the boundary ONE). ? User network element (boundary router) _ NE within the user's domain that is providing a connection to a NE within the service provider's domain. ? User signaling agent (decision point/TE tool) _ Device processing any kind of signaling channel messages and determines need for a link connection on the basis of SLA and related information. Figure 1. General ASON Architecture 3. Business/Commercial Models Before we can consider requirements for the automatic switched optical network services, we must briefly consider the business models that may be applicable and which must be supported. The focus of this section is on business rather than technical issues. Lin, et al. Expires May 2001 6 Requirements on the ASON UNI November, 2000 It is clear that all four models are reasonable and exist today. Indeed, a network might be used in all four ways by various organizations within the same network operator. The most stringent requirements are placed by cases 3 and 4 as both these cases have trust (or security) issues between the service provider and its customer's business, although case 1 also presents trust issues. This need for multiple instances indicates that there is a greater need for partitioning than by technology alone. For this reason there must be support for any desired general partitioning of the network resources, and cases 1 and 2 is handled as a special case where the only partitions are driven by technology and layer boundaries. We note that while ASON is directed primarily to new networks, there is nothing to preclude its use to control existing networks. These potential business models make it clear that support for all types of protocol and carried services is required. We re-affirm that ASON must not assume a single client type and instance. Because of potential trust issues, the ASON network needs to enable segregation of certain information between the user and service provider networks. This for example, may include the topology of the service provider network. 3.1 ISP owning all layer 1 infrastructure The delivered service is transported over the ISP's own layer 1 infrastructure. As the infrastructure is fully owned, there are no trust issues between the infrastructure and service layers (these may be, e.g., different organizations within the same company). The service provider's layer 1 network may support multiple instances and multiple types of user networks. 3.2 ISP owning partial or leasing layer 1 infrastructure The delivered service is transported over part of the ISP's own layer 1 infrastructure or over leased layer 1 infrastructure (e.g., leased from a retailer or wholesaler). As the infrastructure may be leased, there is a trust issue between the infrastructure and the service layers. As the infrastructure may be leased, it may be leased from multiple carriers. Multiple instances of layer 1 networks, owned by more than one player, support multiple instances and multiple types of user networks. 3.3 Retailer or wholesaler for multi-services In this case the business owns the layer 1 infrastructure and sells services to customers who may themselves resell to others. There is a definite trust issue between this business and the client businesses. As this business cannot make any assumptions about the business of the customers, it is highly likely that several customers may be engaged in the same business. This business offers Lin, et al. Expires May 2001 7 Requirements on the ASON UNI November, 2000 many different services to many different customers. If the customers are engaged in the IP business there will be several instances of IP networks running over this network, and each instance will have its own control plane. Layer 1 network supports multiple instances of the user network. 3.4 Carriers carrier, or bandwidth broker Potential users of such an application are other network operators, once removed from delivering service to an end user. In this case there is again a major trust issue. The customer network is likely to be a circuit network, potentially in the same layer as this network (OCh taking part in another operators network) and again there will be several instances of user networks in the same layer each with its own control plane. In this model the provider has no idea what services are being eventually offered by the user network. Layer 1 network may be part of a customer's layer 1 network. This introduces a potential recursion in the business model. 4. ASON 'Dial-up' Service Requirements Prior to the ability to set-up a connection (or lightpath), contract negotiations must be completed and the service level agreements (SLAs) must be in place. These agreements can include, e.g., allowable range of requests for availability (and any associated additional parameters to constrain availability such as MTTR, avoid city X, etc.), ability to set up VPNs, allowable range of signal types and/or bandwidth constraints (e.g., SDH at 2.5 Gbps or MS16), allowable types of traffic priority, etc. As an example, an IP router may request a connection with 'gold' service only if that service was included as part of the contract. Alternatively a client may request the ability to request the entire range of services, e.g., from lowest priority to highest priority. Depending on a particular service provider's policy, all, some, or none of these additional connection set-up attributes may be specified by the customer. For example, instead of specifying some of the distinct attributes, a service provider may offer three classes of services (gold, silver, bronze) that offer specific availability requirements, where each service class may provide different bandwidths. Alternatively, a service provider may only offer basic ASON dial-up service, i.e., set-up (create) connection and release (delete) connection. In addition to specifying attributes of the connection, there needs to be policy control on connection requests. This implies that an enforcement mechanism is needed to ensure compliance of the requests with the service contracts agreed to by the client. This may include, e.g., call acceptance agent (or connection admission control or policy control). An essential part of connection oriented networks is call acceptance. It must be possible to control the Lin, et al. Expires May 2001 8 Requirements on the ASON UNI November, 2000 types of connection requests that are accepted by the network. This allows the traffic intensity to be matched to the available network resources as well as allowing various forms of restricted network access. The switched optical network has been described in terms of connection management, connection set up, service discovery, resilience against server faults, address resolution, and addressing. An approach for defining the requirements for the "dial- up" service is to first define a basic service that sets up connections and then think of features that may be added to the basic service. This allows us to separate the various features, enabling them to be implemented or offered separately. In this regard, one service provider may offer only basic dial-up services, while another operator may offer additional services (such as scheduled connection). Some key service features are enumerated below. 4.1 Connection Operations This service sets up a link connection (lightpath) between a user domain's connection point (IP-capable end-point), and may be triggered by either the user signaling agent (decision point or TE tool) or a third party signaling agent. The trigger point may be located anywhere, based on the specific location of the signaling agent. The service provider signaling agent (ONE-C) receives the connection request and handles set-up of the link connection across the service provider domain. There are three essential/basic operations needed for the service: set-up/create, modify and release/delete a connection. Responses to the three requests may be successful connection or failed connection attempt. In addition, there is a need for the destination entity to be able to accept or reject an incoming connection request. ? Set-up (create): The ASON provides its users with the necessary mechanisms to signal to the network its desire to create a new connection between two connection points. Certain attributes are associated with the requested connections. Those attributes are contained in the signaling message handled by the signaling agent, and may contain various basic attributes (such as signal type) as well as optional attributes (such as connection constraints, scheduled connection). ? Modify: This action results in modifying one or more of the attributes associated with a user's connection. This action allows ASON users to adjust connection attributes. It is still unclear what attributes may be modifiable and the effects of modification to the complexity requirements of the control plane. ? Release (delete): Upon signaling of a connection release by ASON user, the network eliminates all the transport resources Lin, et al. Expires May 2001 9 Requirements on the ASON UNI November, 2000 associated with this connection, though a record of the connection should be maintained for administrative (e.g., billing) purposes. It is expected that the network will acknowledge the release of the connection back to the user. There are several types of requests that can be made to change the characteristics of a connection, of which several are identified here as examples: These requests allow users to make changes to their existing connections without violating any existing SLAs. These changes may be disruptive to user traffic or non- disruptive to user traffic, and may be effected via different methods. For example, changing the bandwidth of a connection may be realized by means of two requests: delete existing connection and create new connection (make before break approach). This specific realization interrupts user traffic flow. However, it may also be conceivable in certain cases that changing a connection's characteristics will not disrupt existing traffic. For example a service provider offers an Nx2.5 Gbps as a single service (i.e., from the user's perspective this is a single connection), and a user initially requests 3x2.5 Gbps connection (as a single request from the user). If the user expects lower use of the connection, the user may request modification of the bandwidth, i.e., 2x2.5 Gbps. From the user's perspective, the bandwidth of the requested connection has been reduced without disrupting existing traffic on the two remaining 2.5 Gbps connection. Additionally, a query request should be provided. The query request can be initiated by the user signaling agent or a third party signaling agent to obtain information regarding the connection. These information may include the attributes of the connection, health of the connection, etc. 4.2 Connection Resilience This service is so named to distinguish it from the protection and restoration mechanisms that are used to provide fault tolerance to the connection. The service adds the ability to tolerate faults to the basic connection set-up service itself. Any parameters to this service must be in terms meaningful to the client, e.g., availability, MTTR, and may not specify server layer architectural solutions, e.g., diversity, specific route (these parameters are associated with, e.g., a carrier's network engineering to achieve the specified availability). In this service we must recognize that various faults may be protected against, and the most important characteristic of the fault is how much physical space it affects. It is likely that such parameters are in terms of fault radius, as well as availability. This is important as the degree of diversity required depends on the size of the fault. Earthquakes, for example, Lin, et al. Expires May 2001 10 Requirements on the ASON UNI November, 2000 affect a wide area yet a service request may well want resilience in the face of an earthquake. Consequently, although availability may be sufficient for specifying resilience, ASON signaling should also consider optional additional attributes to allow connection constraints (discussed in later sections). 4.3 Signaling Network Resilience A Signaling Network (SN) is necessary to serve as the transport network for all the signaling messages necessary for connection setup and teardown within the server layer network (SLN). The SN is the network interconnecting the ASON signaling agents (ONE-Cs). The SLN is the network interconnecting the service provider domain's network elements. It is extremely desirable that the SN topology be independent of the SLN topology (they may use some common physical routes but we do not require or exclude it) and further that it itself be built on top of any SLN technology such as optical, SONET or Ethernet. This makes the SN portable and applicable to any automatic switched network. However, this flexibility creates some challenges. First, note that the SN can have some failures of its own such as cable cuts. These may or may not be coupled with SLN failures depending on the SN and SLN topologies and the packaging of various control plane functions. When the SN has an independent failure, it may impact new connection setup in the SLN as no signaling paths may be available in the SN. When the SN has a failure coupled with a SLN failure, it may not be possible to restore existing connections in the SLN even though alternate paths are available in the SLN. Clearly, this implies that the SN has to be as reliable as the SLN itself (and possibly more reliable than the SLN) and one needs fast restoration in the SN itself in order to carry out the same for the SLN. 4.4 Connection Parameters This section provides additional connection attributes that allow a user of the ASON network to specify additional criteria above and beyond what is sufficient (e.g., availability is sufficient for connection set-up; however, users may demand attributes for additional flexibility). There needs to be a means of attaching attributes to a particular connection request. ? Route diversity - It is conceivable that there is a need for multiple connections to be set up in one operation. An obvious application is the provision of two diverse connections so that a user link connection can provide fault resilience. This can only be provided by specifying constraints on the connections, and these constraints will be comparable with those needed in the resilience service. It is not possible to specify these needs in terms of a potential solution (e.g., explicit route Lin, et al. Expires May 2001 11 Requirements on the ASON UNI November, 2000 across the service provider domain), as the user network has no view of the service provider network's name space and connectivity. A user signaling agent may request an availability value that will necessitate the service provider signaling agent to, e.g., provide a diverse route against faults in the service provider domain, or additional optional attributes to avoid a geographic location due to high occurrence of faults. ? Priority level - Indicates both the set-up and the holding priorities of the connection. A higher set-up priority connection could pre-empt a lower holding priority connection if network resources are scarce during the connection establishment time. Again, the capability (and constraints) of the user to request certain priorities are assumed specified during the contract negotiation phase. 4.5 Scheduled Connection Scheduled connection request provides the user with the capability to set-up connections at a pre-determined time for a pre-determined duration. This document does not describe how this feature may be implemented or what policies to choose from a service provider's perspective (e.g., to provide schedule service, partition the switched network into non-scheduled partition and scheduled partition whereby the latter does not depend on the former). Although this service may be provided as part of the user's own management of the connection request (e.g., user initiates the connection request at the time that is needed), applications of this service may be routine/repetitive automatic operations that occur at specific times (e.g., database back-up every Saturday at 2am) and may be handled by the service provider. It is highly desirable that support for scheduling is in the O-UNI independent of whether the service functionality resides in the control plane or the management plane. Otherwise there will be a need for two separate control channels to the same user and this would be very undesirable. The ability for scheduled services may be provided by the user themselves (via automatic or manual provisioning) or by the service provider. If provided directly by the user, the UNI does not require specific attributes. If provided by the service provider, the UNI may require specific attributes to signal the scheduled connection service. 4.6 ASON Service Level Agreements As mentioned above, connection requests issued by a user signaling agent are only accepted within the constraints of a SLA. In the following text, we discuss the technical aspects of an SLA. A SLA is considered to be unidirectional and to specify performance Lin, et al. Expires May 2001 12 Requirements on the ASON UNI November, 2000 expectations for the user network as well as imposed reachability constraints, e.g., closed user group (CUG). SLA parameters could, e.g., include: ? Capacity parameters A source connection point may contain limits on the maximum number of connections that can be established from a specific ingress point, possibly as a function of time of day, as well as bandwidth constraints (e.g., due to limitations of the fiber facility). A sink connection point may put capacity constraints on the connections that the receiving user network is willing to terminate (e.g., source-end user requests an STM-64; however, destination-end user can only support up to STM-16). ? Service performance parameters Examples of service performance parameters include: reliability/availability (which may be used by the service provider network to determine routing constraints), protection/restoration options, priority (e.g., specifying the pre-emptibility of the traffic), etc. ? Constraints on the 'scope' of connection requests (call acceptance agent, VPN) This may be viewed as an extension to the concept of CUGs, which by nature already exhibit reachability limitations. Scope constraints are intended to additionally restrict the topological extent of connections. In its simplest form, the SLA offers to accept any connection request issued by the user signaling agent up to a maximum capacity without any scope constraint within the CUG, e.g., within a company's VPN. Conversely, the agreement may be constrained by the egress point of a connection. For example, the switched optical network might agree to the setup of connections, up to a certain maximum capacity, but only if these connections are destined to a specific set of egress points within the CUG that supports these connections. Part of the purpose of SLAs is to protect resources in the service provider network by validation of submitted connection requests. If the service provider network and the user network are under control of the same administrative authority, then there is likely to be a trusted peering relationship between both domains. Conversely, in case of an untrusted peering relationship, the ASON service provider validates incoming connection requests via the call acceptance agent as per the pre-negotiated SLA. Alternatively, the SLA enforcement may be outsourced to another policy entity. The call acceptance agent offers to accept connection requests at the service level agreed with the user. The service provider will provision the switched optical network accordingly. A broad range of optical services could be envisioned. As an example, services could be defined with different levels of accessibility, depending on the Lin, et al. Expires May 2001 13 Requirements on the ASON UNI November, 2000 probability that a connection establishment request is blocked. Moreover, services could also be categorized as protected or non- protected, depending on the offered protection level. All of these service level characteristics influence the resource provisioning process in the switched network. For each connection request, the ASON service provider may also need to identify the SLA for which the request is submitted. Some authentication may be included in the request in order to verify that the rightful user issued the request. In some cases, this authentication information might be implicitly derived from the signaling channel on which the connection request was received. The security mechanism must be specified in the SLA. This security mechanism may include only user authentication, or may include tighter security measures such as confidentiality and non- repudiation (e.g., public key distribution and certification). Although it can be assumed that SLAs will be static for the foreseeable future, this document does not preclude dynamic SLAs. These would necessitate some automated form of interaction between the user and the service provider. In case of a SLA at the O-UNI, this may for instance require the interaction between a Bandwidth Broker (BB) in the user domain and a Lambda Broker (LB) in the service provider domain. At the level of an O-NNI, this would be between different LBs, acting on behalf of the different transport subnetworks. This automated (re-)negotiation of SLAs would in turn call for an automated call acceptance agent function. Note that this call acceptance agent function is different from the validation of connection requests as per the negotiated SLA, referred to as SLA enforcement, since it provides for automated negotiation of the acceptance parameters. 4.7 Naming and Addressing Naming and addressing requirements involve creating the bindings between: (a) the user domain names and service provider domain names (e.g., service provider identification), and (b) layer network names (e.g., ODUk). These two scenarios are depicted in the following diagram: Lin, et al. Expires May 2001 14 Requirements on the ASON UNI November, 2000 Figure 2. User-Service provider, Client-Server Layer name Translation An example of the layer network name translation is as follows: layerN represents the SDH layer network, where layerN-n is the OSn. LayerM represents the OTN layer network, where layerM-m is the OTSn. In this case, the semantics of the name associated with the user domain's layerN-n is specific to the user's layer network. A differentiation between a name and an address may be viewed as follows: Name - an opaque string with no semantics other than sufficient uniqueness. Address - a structure that is used for routing, and so may include additional semantics such as the ability to be compared for "closeness". Value (of name or address) - may be both an address and a name to different parties, e.g. a string that is an address to a server layer could be used as a name by a client layer (and vice versa), but to do so may expose some privacy/security issues, and may well prevent the client from choosing a name that is useful to it. Separation of server layer name and client layer name, as well as user domain name and service provider domain name, provides an abstraction barrier between name processing and connection operations. Some properties of the naming and addressing in the switched network are: name independence, name uniqueness, and name translation. These properties apply to both the client-server as well as the user-service provider relationship. ? Name independence - The client (user) name should not make assumptions on what capabilities are offered by the server (service provider) name, and thus the semantics of the two name spaces should be separate and distinct. This does not place any Lin, et al. Expires May 2001 15 Requirements on the ASON UNI November, 2000 constraints on the syntax of client and server layer name spaces, or of the user and service provider name spaces. ? Name uniqueness - In order to uniquely identify user requests and subsequent identification of the connection set-up, it is desirable for names associated with a user request to be unique within the service provider network. Note that a pair of user nodes may have multiple connections between them, thus user name pair is not sufficient to identify a connection. In cases where user name uniqueness is not possible, specific actions needs to be described, e.g., the service provider will choose them sequentially in some fixed sequence decided by the service provider, the distribution will be uniform. ? Client handle - To uniquely identify a connection in the server layer, a client handle is transmitted to the client as a result of successful completion of a connection request. Because the server layer is circuit-switched, this client handle is only identified and used at the ingress and egress of the server network to map specific client traffic onto an established connection, and no congruence is assumed between the server layer access point and the client layer connection point. The client handle should be unique for all connections in the client name space. As an example, a client handle can be formed from concatenation of the A-client-endpoint-name:Z-client- endpoint-name:timestamp. ? Server (service provider) name space - The server layer and the service provider name spaces provide identification of the node and the resources available for connection operations and is a NNI issue. Server names are applicable at the server layer only, and should not be communicated to the client layer. ? Name translation - Name translation serves multiple purposes. The translation function may provide mapping of the client layer name to server layer name (used for routing decision through the server layer), user domain name to service provider domain name, or provide mapping of client handle to a connection in the server layer. These translation functions will likely be performed via a (or more) directory service(s). The directory function must respect and enforce the privacy of the technology layer namespaces from each other. Each technology layer instance will have its own namespace that is independent of all others. The directory function must also respect and enforce the privacy of different user domain name spaces from each other (e.g., used in CUG or VPN services). Ownership of the directory service may be an issue, i.e., service provider owned or user owned. This is outside the scope of the UNI requirement. The following table shows the applicability of these properties to the client-server and user-service provider name/address requirements: Lin, et al. Expires May 2001 16 Requirements on the ASON UNI November, 2000 Table 1. Properties of Client-Server and User-Service provider Relationships +----------------+----------------+----------------+ | | Client-server | User-service | | | | provider | +----------------+----------------+----------------+ | Name | Independence | Independence | | Independence | needed | needed | +----------------+----------------+----------------+ | Name | Uniqueness | Uniqueness | | Uniqueness | needed | needed | +----------------+----------------+----------------+ | Name space | No sharing | No sharing | | sharing | | | +----------------+----------------+----------------+ It is also possible that a client (user) may wish to register more than one name as an alias (equivalent to having several directory entries for the same telephone number), as it is possible that the client (user) will wish to register the same name for several end points (to create access groups). This feature need not be available on all infrastructures. Example applications involve clients that want names in several name spaces or simple aliases in the same name space. The service must therefore provide primitives to: Register, Modify, and Remove name bindings: ? The client API shall provide a service to register the client name with the network. This service may be provided as either a client or a server initiated operation. It shall have been used before the connection set-up service can be used, and may be used at any later time to register new client names (aliases). ? The client API shall provide a service to modify a registered client name. This may be used at any later time to change the client name and shall have no affect on any connections that are established to or from this client at the time that the name is changed. ? The client API shall provide a service to remove a registered client name. At the same time that the names are being bound, the service shall verify the connectivity between the client and the server. A mechanism to accomplish this is required. Note that this operation does not of itself enable the connection service. It is necessary that the user be able to connect to an appropriate service provider before the ASON dial-up service has been established. It is expected that this will be accomplished by a Lin, et al. Expires May 2001 17 Requirements on the ASON UNI November, 2000 well-known service provider address (possibly a URL) with security established (manually or automatically) as part of the contract. This model is widely used today, as many contracts supply unique information allowing the user to access online services after the contract has been established. 5. Set-up of ASON Network The main operations supported by the client layer API are associated with the setting up and tearing down of Optical Channel 'calls'. In addition to the Set-up and Release operations, there may be a need for a 'dial-tone' operation. This is to signal to client equipment that there is a connection service available. This covers the case where hardware is installed and the client is connected to ASON but there is no contract established. It seems reasonable that the client can discover the availability of the service without having to make a test call. As previously mentioned, calls are made between two user network elements, traditionally called the A end and the Z end. It must be possible for both participants and third parties to set-up calls, and it must be possible to have a control plane that is not associated with the connection being set-up. These requirements mean that the set-up operation must have both the A and Z end user network element name in the set-up request. 5.1 Operations Phases There are several phases in the operation of a switched optical network and it is important to understand to which phase a particular requirement applies. These phases are 1) Contract Negotiation, 2) Equipment Installation and 3) Connection Service usage. Each phase requires interaction between the user and the ASON service provider and both one and two must be completed before the connection service is available. There is no constraint on the order of step 1 and step 2, which means that it is quite feasible to have a user connected to the service provider network who does not yet have a contract, and who therefore cannot make connection requests. It is obvious that the client API cannot provide any meaningful functionality during equipment installation (software after all cannot install hardware), and it is not necessary that the API provide any of the functions required during contract negotiation. ASON is about the automation of connection set-up, and not about contract automation. However it is expected that the vast majority of clients will be machines, not people, so some degree of automation could be applied. An important part of configuring a user for automatic switched service is name binding, the process by which the user name is bound to the corresponding network name, and entered into a directory. Lin, et al. Expires May 2001 18 Requirements on the ASON UNI November, 2000 This directory may be owned by the service provider to preserve the security of the names and addresses. Suffice it to say here that the directory services should accept user defined names on the connection set-up interface (the main service of the Client API) and the directory service is responsible for mapping those names into the names of server layer ports between which connections are actually made. A further requirement is to automatically check the client-server connectivity and the user to service provider connectivity at the same time that these names are bound. Note that successfully binding the names does not imply that the connection service is available. This depends on all aspects of the contract being completed. 5.2 Connection Phases As mentioned above, connection set-up undergoes three steps: set-up (create), modify (optional), and release (delete). Also included as part of this phase is a query request. The following figure provides a high-level state diagram of the state transition of the ASON service. Note that the state diagram may be expanded to include more detailed transitions, e.g., the _create connection_ link may be expanded to include the detailed transitions of the create request (verify policy controls such as security, verify successful mapping of user parameters to service offerings, etc.). Figure 3. General State Diagram of ASON Network 5.2.1 Set-up (Create) Connection Lin, et al. Expires May 2001 19 Requirements on the ASON UNI November, 2000 Several attributes may be associated with a connection set-up. Depending on the offered service, several of these attributes may be optionally provided as part of the request. The user signaling agent or a third party signaling agent may initiate the connection set-up request. The user signaling agent is not required to be in tha same physical location with the end-point for which it signals. This is especially important in supporting third party signaling. ? Contract SLA It should be possible to request the specific pre-negotiated (or dynamically negotiated) contract SLA for the specified connection set-up request. The SLA may include the specific availability, MTTR, ability to specify avoiding areas of failure (or SRLGs), etc. Some or none of these additional attributes may be included, as determined by negotiation between user and service provider (e.g., service provider may only offer three grades of SLAs: gold, silver and bronze service) ? Service type/bandwidth or service name It should be possible to request the specific pre-negotiated (or dynamically negotiated) service type and bandwidth (e.g., SDH at 2.5 Gbps) or service name (e.g., MS16) for the specified connection. The service name may embed other information regarding the possible attributes of the connection, e.g., possibility to modify certain attributes associated with the service, the directionality of the service (uni or bi), etc. These additional attributes may or may not be required. ? VPN Service It should be possible to request the specific pre-negotiated (or dynamically negotiated) connection within a certain closed user group/VPN. Associated with this request are security measures needed to ensure that the request does in fact have authorization to make the request. This is especially true for third party signaling, which may require authentication, confidentiality and non-repudiation for the request. Generic procedures need to be defined to realize the connection set- up process, taking into account the above requirements. Assuming that physical resources have been discovered (either by auto- discovery or manual provisioning): ? Connection set-up request is received containing a client/user name, along with connection-specific constraints relevant to the client's SLA (capacity/bandwidth, availability/radius of failure/area to avoid, pre-emptibility/priority, connection start time, connection duration). ? Call acceptance agent and security measures are needed to ensure that the client request remains within the bounds of the pre-agreed contract services. Lin, et al. Expires May 2001 20 Requirements on the ASON UNI November, 2000 ? Connection request name mapping is performed to establish name bindings (client/user name mapping, area constraint name mapping). ? Based on connection start time, routing procedure (e.g., optical BGP) may be initiated to establish a connection, or processes are initiated to handle scheduled services. Note that for scheduled service requests, several options may be available, again based on business model and contract negotiations, e.g., establish/reserve connection immediately or establish connection at the scheduled time in the network partitioned to support scheduled connection. ? Based on connection duration, a connection release request may be automatically generated and placed in release queue for specific release time. ? Results of the routing procedure determines whether a connection request is satisfied (in which case a client handle is created), or whether request re-tries may be made (in which case the connection request may be placed back in the request queue with necessary back-off mechanisms) ? A status message is passed to the user domain (or third party) upon successful or failed connection attempt. 5.2.2 Modify Connection A modify connection request may be needed for networks where certain connection attributes may be changed. The user signaling agent or a third party signaling agent may initiate the connection modify request. The modify request should not violate any existing SLAs, i.e., policy control. As it may not be possible to satisfy these modification requests, status messages are needed to signal success or failure of the request. ? Connection name (client handle) The connection to be modified shall be indicated by the client handle obtained from a previous set-up operation. Optional attributes should be provided to indicate the desired modifications. Agreements on the extent of traffic interruptions (if any) should be made clear between the user and service provider (either via automated negotiation or during contract set-up). Note that the user may _view_ the modify request as a change of the connection characteristic, however the client handle may not be changed. ? Return values - Connection status It must be possible to signal successful or failed modification request. 5.2.3 Release (Delete) Connection Lin, et al. Expires May 2001 21 Requirements on the ASON UNI November, 2000 Certain attributes are needed to affect the release of a connection. The user signaling agent or a third party signaling agent may initiate the connection release request. ? Connection name (client handle) The connection to be torn down shall be indicated by the client handle obtained from a previous set-up operation. ? Return values - Connection status It must be possible to signal successful disconnection. Capabilities should be specified to allow for automated connection release upon failure of the release request. 5.2.4 Query Connection Related to the connection request is the querying a connection. The user signaling agent or a third party signaling agent may initiate the connection query request. ? Connection name (client handle) The queried connection shall be indicated by the client handle obtained from a previous set-up operation. Associated with the query request are information/attributes that are being queried. These may include a list of the desired attributes, or default the entire list of attributes associated with the queried connection ? Return values - Connection status A message is passed to the user domain (or third party) containing the queried information. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Lin, et al. Expires May 2001 22 Author's Addresses Monica Lazer, AT&T Tel: 908-234-8462 Email: mlazer@att.com Curtis Brownmiller, Worldcom Tel: 972-729-7171 Email: curtis.brownmiller@wcom.com Zhi-Wei Lin, Lucent Tel: 732-949-5141 Email: zwlin@lucent.com Vijaya Poudyal, Telcordia Tel: 732-758-3192 Email: vpoudyal@telcordia.com Philip Walch, TyCom Tel: 732-578-7150 Email: Pwalch@tycomltd.com Mark Jones, Sprint Tel: 913-534-5247 Email: mark.jones@mail.sprint.com Olivier Duroyon, Alcatel Tel: 703-654-8605 Email: oduroyon@adn.alcatel.com Jen-Wei Kuo, Fujitsu Tel: 919-790-2033 Email: jen-wei.kuo@fnc.fujitsu.com Yang Cao, Sycamore Tel: 978-367-7173 Email: yang.cao@sycamorenet.com Hirokazu Ishimatsu, Japan Telecom Tel: +81 3 5540 8493 Email: hirokazu@japan-telecom.co.jp Yong Xue, UUNET/Worldcom Tel: 703-886-5358 Email: yxue@uu.net Full Copyright Statement Lin, et al. 23 Requirements on the ASON UNI November, 2000 "Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Lin, et al. Expires May 2001 24