Internet Draft IETF Working Group Zhi-Wei Lin, Lucent Internet Draft Technologies Expiration Date: May 2001 Hirokazu Ishimatsu, Japan Telecom Olivier Duroyon, Alcatel Jim Jones, Alcatel Curtis Brownmiller, Worldcom November 2000 UNI and NNI Operations and Generic Parameters draft-lin-mpls-uni-nni-oper-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 This draft presents the transitional phases that optical network connection operations undergo, providing high-level processes and states of the connection operations. A list of potential parameters associated with the connection operations signaling protocol is provided. The list of parameters is not an exhaustive list; it should be used as a basis for more comprehensive parameters for the signaling mechanism. Lin, et al. 1 UNI and NNI Operations and Parameters November 2000 Table of Contents 1. Introduction....................................................3 2. ASON Connection Operations Time Line............................3 3. UNI Connection Operation Transition Diagram....................11 3.1 UNI Create Connection.........................................12 3.2 UNI Delete Connection.........................................13 3.3 UNI Modify Connection.........................................14 4. NNI Connection Operation Transition Diagram....................15 4.1 NNI Create Connection.........................................17 4.2 NNI Delete Connection.........................................19 4.3 NNI Modify Connection.........................................21 5. Parameters for UNI and NNI DCM.................................22 5.1 Possible parameters for the UNI signaling protocol:...........25 5.1.1 UNI Create..................................................25 5.1.2 UNI Delete..................................................26 5.1.3 UNI Modify..................................................26 5.1.4 UNI Query...................................................27 5.1.5 UNI Notification parameters.................................28 5.2 Possible parameters for the NNI signaling protocol:...........28 5.2.1 NNI Determine route.........................................28 5.2.2 NNI Create..................................................29 5.2.3 NNI Delete..................................................30 5.2.4 NNI Modify..................................................30 5.2.5 NNI Query...................................................31 5.2.6 NNI Notification parameters.................................31 Lin et al. Expires May 2001 2 UNI and NNI Operations and Parameters November 2000 1. Introduction Various standards bodies are working to define the signaling protocols used in realizing an automatic switched optical network (ASON). These activities concentrate on the mechanisms and the message sets for communication of user-to-service provider connection requests, and communications within service provider domains for connection operations. This draft presents the transitional phases that optical network connection operations undergo, providing high-level processes and states of the connection operations. A list of potential parameters associated with the connection operations signaling protocol is provided. The list of parameters is not an exhaustive list; it should be used as a basis for more comprehensive parameters for the signaling mechanism. 2. ASON Connection Operations Time Line Time T0: The initial state of the ASON network. There are no connections among the NEs, nor is there any apparent UNI or NNI established. This state represents a pre-deployment of the network. Time TA: After installation/deployment of the NEs, discovery occurs within the service provider domain. This discovery phase may include neighbor discovery (including the connectivity and facilities between adjacent NEs) and possibly service discovery (e.g., what are the possible signal types in common between them). The result of this phase is the establishment of the NNIs among the NEs (NNI-S and NNI-T).{1} For example, during neighbor discovery, a node ID may be exchanged with each NE's adjacencies. Along with a node ID, a port ID may also be exchanged. The port ID provides the highest level view of the connectivity between adjacent NEs. This information may be populated into an adjacency Table containing the adjacency node IDs and their respective port-pair connectivity (link) IDs. Alternatively, this information may be manually provisioned into Tables. Prior to resource discovery {2}, it is assumed that the respective NEs have undergone a local self-discovery (manual population of the Tables or automatic discovery of the resources), where the NEs may ------------------- 1 Since the service provider control plane components may be separate from the transport NEs, these NNIs may be (a) between two transport NEs, (b) between a transport NE and a control plane NE, or (c) between two control plane NEs. 2 While telephony may traditionally refer to connections in use as service connections, it is the resources that can potentially by used for service connections that is discovered. Lin et al. Expires May 2001 3 UNI and NNI Operations and Parameters November 2000 populate a service Table which lists the types of services that it can support (e.g., STS-1, STS-3c, STS-12c, ODUk, OCh, etc). During service discovery, adjacent NEs exchange information regarding their common service supports. For example NE #1 may support DS3, STS-1, STS-3c, STS-12c while NE #2 may support STS-1, STS-3c, STS-12c, STS- 48c. In this case the only service that may be offered between NE #1 and NE #2 will be the set of services common between the NEs (STS-1, STS-3c, STS-12c). This list may be exchanged and negotiated during discovery or a crafts personnel may provision this information into the NEs. Service discovery also includes the number of these services that may be supported, i.e., how many STS-1s may be set up between two nodes. A service availability Table may be populated with the discovered service information, including the service name (STS-1) and possibly an index into these STS-1s (index #1 represents STS-1 #1, index #2 represents STS-1 #2, etc). Obviously this stage is technology dependent. Format of the index, reference to these service names may be provided either via a generic service name or a technology dependent service name; this is outside the scope of this document. Figure 1. Example Network Configuration Showing Node, Link/Port, Subchannel For example, for the example network configuration shown in Figure 1, an adjacency Table, service Table, and service availability Table may be conceptually represented as follows (these Tables may be automatically populated or manually provisioned; they may also have Lin et al. Expires May 2001 4 UNI and NNI Operations and Parameters November 2000 different formats and different information representation _ these Tables show an example which is likely not complete for route determination purposes): Table 1. Example Conceptual View of Adjacency Table (e.g., Provide Link Information) AdjacencyID EAST Side WEST Side 1 A:i 2 A:ii 3 C:i 4 D:i 5 E:i Table 2. Example Conceptual View of Service Table ServiceID Services 1 2.5G 2 10G Table 3 Provide Link Connection and Availability Inform . Example Conceptual View of Available Service Table (e.g., ation) AvailServID EAST Side(format Available AdjacencyID:LinkConnection:Se rviceID) 1 1:1:1 Yes 2 1:2:1 No 3 1:3:2 Yes 4 1:4:2 Yes 5 2:1:1 Yes 6 2:2:1 No 7 2:3:1 Yes 8 2:4:1 No 9 3:1:1 Yes 10 3:2:1 No 11 3:3:2 Yes 12 3:4:2 No 13 4:1:1 Yes 14 4:2:1 Yes 15 4:3:2 No 16 4:4:2 Yes 17 5:1:1 Yes 18 5:2:1 No 19 5:3:2 Yes 20 5:4:2 No Lin et al. Expires May 2001 5 UNI and NNI Operations and Parameters November 2000 Time TB: At this stage, the service provider is set to offer services to users. This phase includes the neighbor and service discovery between the service provider NE and the user NE.{3} Associated with this phase is the contract negotiation and SLA agreement between the service provider and the user (this may be automated or manual). At this point, there is no difference between A-end user or Z-end user.{4} The result of this phase is the establishment of the UNIs between the NEs (UNI-S and UNI-T). Similar to the NNI discovery phase, the UNI discovery undergoes similar steps in the neighbor and connectivity discovery, and the service discovery. Time TC: At this stage, it is assumed that the user and service provider have established an agreement regarding contractual and SLA constraints, and the possible type of services that the user may request (e.g., only provide 3 class of service). The A-end user initiates a connection request via UNI-S signaling channel (this signaling channel may be in-band or out-of-band or a completely separate network; no recommendation is made regarding this). For example using the above network configuration and Tables, the A- end user is represented by node A and is connected to B and it needs to connect with the Z-end user at 2.5Gbps rate, the user may look up its available service Table (which would have been discovered and synchronized with the service provider available service Table), and signals that the UNI A-end link will use AvailServID #5. In this case, all information regarding that signal (such as signal type, rate, port ID, subchannel) is embedded within the ID number. The service provider receives the connection request, and starts the process that results in allocating the required resources. During this stage, route determination needs to be performed by the service provider domain. Several methods may be employed in determining the route: The service provider NEs have routing engines built-in, in which case a source routing method may be employed The routing engine is separated from the NEs, in which case a signaling message needs to be propagated to this routing engine to request an explicit route. In certain cases a service provider may employ multiple routing engines (e.g., an OSPF, BGP, IS-IS, personnel, others). An identifier may also be desirable to allow the NNI to use a specific routing engine. ------------------- 3 This may include possible combination adjacencies of (a) service provider transport NE, (b) service provider control plane NE, (c) user transport NE, and (d) user control plane NE. 4 A-end and Z-end are used in the context of a user link connection request. A-end user is the user that initiates a connection operation (either via direct signaling or via third-party signaling). Lin et al. Expires May 2001 6 UNI and NNI Operations and Parameters November 2000 Hop-by-hop routing may be used. In this case, each node determines its next hop. Associated with this comes all the issues that has been discussed in the industry associated with hop-by-hop routing (such as potential loops). Hop-by-hop routing is not the desired solution in the ASON network. One possible method for this allocation may be: to prevent unnecessary resource allocation/de-allocation and route determination within the service provider domain, the service provider (a) allocates resources for the UNI A-end link connection and the UNI Z-end link connection (adequate resources, meets SLA constraints, etc.), and (b) allocates/establishes the NNI subnetwork connection (SNC) across its domain. The result of this phase is (a) successful establishment of the user UNI link,{5} or (b) failure notification to the user in which case the allocated resources need to be de-allocated. Other methods for establishing the UNI link may be: Reserve resources after receiving the request, and allocate resources after receiving the response (or un-reserve if failure downstream) Allocate resources after receiving the request (de-allocate if failure downstream) Reserve and allocate resources after receiving the response This document does not make a proposal on which method works best. There are advantages and disadvantages to each method (e.g., with #1 there will be no unnecessary link resource allocation, whereas for #2 link set-up is likely faster and will be beneficial for fast restoration of the connection) Time TD: At this stage, the user has completed use of the connection and initiates to delete the connection. The service provider receives the connection delete request, and starts to de-allocate the resources. The result of this phase is the removal of the user UNI link. Figure 2 provides a high-level temporal view of the DCM connection operations (signal flow) as described above. ------------------- 5 Note that the user UNI link is composed of: (1) the UNI A-end link, (2) the service provider SNC, and (3) the UNI Z-end link. Lin et al. Expires May 2001 7 UNI and NNI Operations and Parameters November 2000 Figure 2. ASON DCM Connection Operation Signal Flow Note that during the user connection request phase, a message may need to be communicated to the Z-end user to notify the Z-end that a connection is been requested by the A-end user (time TC+x). This step may or may not be necessary depending on the type of services offered, possible connections, whether users are within a VPN, etc. For example, to prevent _denial-of-service_ attacks on the Z-end or as a _firewall_ capability, the Z-end user may only want to allow certain users to connect. In such instances, the service provider needs to signal the A-end user connection request to the Z-end user (via the Z-end user UNI-S).{6} Because this signaling message passes the UNI interface, the UNI signaling protocol is used. Alternatively, using telephony services as an example, A makes a call to Z. At the Z end, telephone rings to notify Z of an incoming call. Optionally, Z may have caller-ID or call blocking feature ------------------- 6 User names (and user group names) used in the messaging exchange will have been registered with the service provider prior to services. Lin et al. Expires May 2001 8 UNI and NNI Operations and Parameters November 2000 enabled (these could be caller verification). These features allow Z to identify the A caller, and allow Z to make a decision whether or not to receive the call. Taking this analogy a step further, for the ASON, verification of the A-end user by the Z-end as well as other capabilities such as service verification (e.g., Z-end may only accept certain A-end requests for certain signal types) may be important. It is obvious that this verification may be performed at different locations. For example, The service provider may offer to provide such connection constraints; however, there may be confidentiality constraint that prevents this set-up. In this case, no information needs to be passed to the Z-end user. The Z-end link connection may be set-up via capacity allocation by the service provider. The user handles connection constraints. In this case, the service provider only needs to pass relevant information to allow the Z-end user to make the verification. This may be done by passing through the A-end user request message to the Z-end user. Note that in this case, the role of the user and service provider has been reversed, i.e., at the A-end the user makes the request and the service provider responds to the request, at the Z-end the service provider makes the request and the Z-end responds to the request. Thus, the UNI serves two purposes: UNI signaling as a user-initiated message communications (or third- party on behalf of the A-end user) UNI signaling as a service provider-initiated message communications The ODP terminology is used in this document when discussing the functions of the ASON in the connection operations. These terms refer to a performer and an agent. In the context of this document, the following definitions are used: Performer and performer factory represent computational objects within a Computational viewpoint. They embed the specific operation that needs to be invoked during the connection operation. For example, a method of a link performer may be invoked in allocating a link connection. Agent represents communication within an Engineering viewpoint, and provides for interaction among performers. For example, a signaling agent may be used in the connection set-up process managed by various performers. Link performer factory: Analogous terms for the link performer factory are the directory and name translation. The link performer factory provides the functional capability to bind names and instantiates the link performer associated with the link resources. The directory handles database population of registration of user and service provider names as well as information on name Lin et al. Expires May 2001 9 UNI and NNI Operations and Parameters November 2000 translations. The name translation handles translation of user domain name to service provider domain name, as well as translation of client layer name/address to server layer name/address. Link performer: Analogous terms for the link performer are link management and traffic policing. The link performer provides the functional capability to control the availability of resources, and the allocation of resources. This performer handles resource allocation (based on results of subnet performer) and resource contention. Re-routing based on restoration or protection switching is another capability handled by the link performer, in coordination with other link performers and subnet performer. Subnet performer: An analogous term for the subnet performer is the routing engine. The subnet performer provides the functional capability to determine a path through the service provider network, e.g., based on routing algorithms (e.g., shortest path, disjoint path, etc.). This performer coordinates with the link performer to establish a subnetwork connection through the service provider network. The subnet performer provides a view of the network connectivity (topology). Discovery performer: The discovery performer provides the functional capability to establish the adjacencies of the port-pairs. This performer handles the topology information (neighbor discovery of both the control network and the transport network) and the services available in the network (service discovery). The discovery performer may be used during the discovery phase (out of scope of this document). Policy performer: The policy performer provides the functional capability to verify and ensure compliance with pre-established contract SLAs. This performer may also handle the authentication, confidentiality, and possibly non-repudiation services based on the level of security needed. The performer uses the security information provided by the security parameter (if provided) or coordinates with the underlying secured network (such as IPSec). Lin et al. Expires May 2001 10 UNI and NNI Operations and Parameters November 2000 3. UNI Connection Operation Transition Diagram From the user's perspective, the ASON connection operation can be logically separated into two parts. The first part is the A-end user connection request signaling to the service provider. The second part is the service provider set-up process to establish the UNI link. The service provider set-up process may include (a) the A-end UNI link set-up, (b) the NNI subnetwork connection set-up as well as (c) the Z-end UNI link set-up. This last statement assumes that the A-end user and Z-end user may not be within the same domain, and thus a separate signaling message is sent to the Z-end user for the Z-end link connection set-up. To set up the UNI Z-end link, a separate signaling message is sent to the Z-end user for the Z-end link connection set-up, e.g., allocate resources for the UNI set-up. If the A-end and Z-end are within the same administrative domain, no verification is needed and the A-end/Z-end link connection may be affected by allocation of resources. Figure 3 provides a high level transition diagram for the UNI connection operations. Figure 3. High-Level UNI Connection Operation Transition Diagram The state of a connection may be represented as going through a series of events. These include: Lin et al. Expires May 2001 11 UNI and NNI Operations and Parameters November 2000 Discovery phase. This phase include the contract set-up, discovery of the signaling UNI, and discovery of the transport UNI. Within this phase, contract modifications may also be made, e.g., add or remove additional service classes. Connection phase. This phase include connection operations, such as create connection, modify connection and delete connection. These connection operations undergo several steps such as route determination (directory lookup), and flexible configuration (e.g., provide an STS-3c within OC-48), and capacity allocation. This document does not discuss the contract phase (out of scope of document). 3.1 UNI Create Connection Figure 4 illustrates the various processes (and the states) that acts on a UNI create request. Note that the processes are contained within the service provider domain. The user domain views the state of the request, i.e., from _no connection_ to _UNI link established_. Figure 4. High-Level UNI Create Connection Operation The processes within the service provider domain are split into a policy/admission control (which may be handled by the policy Lin et al. Expires May 2001 12 UNI and NNI Operations and Parameters November 2000 performer) and the link performers. The UNI link may be sub- partitioned (not shown in the above figure) into A-end link, Subnet connection, and Z-end link, where subnet connection may be further sub-partitioned into subnet connection, link, and subnet connection, and so on, until the _atomic_ subnets and link connections are reached. Examples of atomic subnets and atomic link connections are cross-connect fabrics and fibers, respectively. Depending on the configuration of the user network and the extent of the request, the A-end user has a view of the allocation of the UNI A-end link (i.e., involved in allocating the resources for the A-end link), but the NNI subnetwork connection and the UNI Z-end link are invisible to the user. The policy performer verifies A-end user's request at both the A-end and the Z-end. This ensures that the A-end can in fact request the particular connection, and also ensures that the Z-end can in fact allocate (and allow) the particular resources to the user requested connection. A failed connection request should generate a _request error_ message. This message may be sent to the user (as a response) and sent to a management system of the failed connection. In addition, if the failure occurs during the _NNI create connection_ process, the UNI A-end and Z-end capacity need to be de-allocated. 3.2 UNI Delete Connection Figure 5 illustrates the various processes (and the states) that participates in a UNI delete request operation. The processes are contained within the service provider domain. The user domain views the state of the request, i.e., from _UNI link established_ to _no connection_. Lin et al. Expires May 2001 13 UNI and NNI Operations and Parameters November 2000 Figure 5. High-Level UNI Delete Connection Operation The steps taken to delete a UNI link reverses those of the UNI create connection operation. After verification of user and the policies, the UNI link is de-allocated. This involves interactions of multiple link performers and subnet performers. In the case of a delete command, the above figure makes the following assumption: even though there may be errors during deletion of the connection, the user should be allowed to complete the delete request. This implies, e.g., if _NNI delete connection_ process fails, a _request error_ is sent to the appropriate management system. The process continues to the _de-allocate UNI A- end and Z-end link_ stage. If this stage also fails, a second error message may be sent to the management system. The result may be that the connection remains up, but the user will not have access, nor will they be _billed_ for the service. 3.3 UNI Modify Connection Figure 6 illustrates the various processes (and the states) that participate in a UNI modify request operation. The processes are contained within the service provider domain. The user domain views the state of the request, i.e., from _UNI link #1 established_ to _UNI link #2 established_. Lin et al. Expires May 2001 14 UNI and NNI Operations and Parameters November 2000 Figure 6. High-Level UNI Modify Connection Operation In the case of the modify request, there may be potentially two types of modifications or changes to the UNI link: those that are disruptive (i.e., disrupts the UNI link), and those that are non- disruptive (i.e., in-service modify of UNI link attributes). Whether either or both are needed is for further study. For example, for the case of disruptive change of the UNI link, this may be realized via a create-delete combination. As shown in the above figure, once the modified UNI link has been successfully established, that link (#2) should be provided to the user. However, during the course of deleting the old UNI link (#1), an error may occur that prevents the deletion. As with the previous (delete) example, an error message may be presented to a management system. At the same time, user access is prevented to the old UNI link (#1). 4. NNI Connection Operation Transition Diagram Within the service provider's network, no verification of connection requests are needed. The ASON connection operation can be logically Lin et al. Expires May 2001 15 UNI and NNI Operations and Parameters November 2000 separated into two parts. The first part is the service provider set-up process to establish the UNI A-end and Z-end links (This is included as part of the UNI connection operation). The second part is the service provider set-up process to establish the NNI subnetwork connection. Figure 7 provides a high level transition diagram for the NNI connection operations. Figure 7. High-Level NNI Connection Operation Transition Diagram The state of a connection may be represented as going through a series of events. These include: Discovery phase. This phase includes the discovery of the signaling NNI and discovery of the transport NNI. Connection phase. This phase includes connection operations, such as route determination (either hop-by-hop or explicit route), create connection, modify connection and delete connection. These connection operations undergo several steps such as flexible configuration (e.g., provide an STS-3c within OC-48), and capacity allocation. This document does not discuss the discovery phase (out of scope of document). Lin et al. Expires May 2001 16 UNI and NNI Operations and Parameters November 2000 4.1 NNI Create Connection In its simplest form, the NNI create connection operation is represented as two possible processes: (1) reservation of the route across the service provider network, and (2) allocation of capacity of a subnetwork connection across the service provider network.{7} Figure 8 illustrates this high-level process. Figure 8. High-Level NNI Create Connection Operation Note that the reservation and allocation process may be performed in different combinations. These scenarios may be expected: Reserve resources after receiving the request, and allocate resources after receiving the response (or un-reserve if failure downstream) Allocate resources after receiving the request (de-allocate if failure downstream) Reserve and allocate resources after receiving the response This document does not make a proposal on which method works best. There are advantages and disadvantages to each method (e.g., with #1 there will be no unnecessary link resource allocation, whereas for #2 link set-up is likely faster and will be beneficial for fast restoration of the connection) ------------------- 7 Allocation of capacity may include flexible adaptation (e.g., in SONET, if a user asks for an STS-3c, an adaptation needs to take place to provide that service since the fundamental signal may be an STS-1) as well as allocation of the resource. Lin et al. Expires May 2001 17 UNI and NNI Operations and Parameters November 2000 The subnet performer is the top-level computational object that establishes a cross-connect between the UNI A-end and UNI Z-end connection points. However, the subnet performer works in tandem (i.e., communicates) with other performers to effect the NNI subnetwork connection. Based on how the service provider network is partitioned, the subnet performer may interact with a subnet performer, link performer, and another subnet performer. Each of the link performer and subnet performer may also further interact with its own set of link performers, subnet performers, and so on, until the _atomic_ subnets and link connections are reached. Examples of atomic subnets and atomic link connections are cross-connect fabrics and fibers, respectively. Figure 9 illustrates the recursive/nested (and iterative/cascaded) partitioning of the UNI link, specifically representing one particular partitioning of the subnetwork connection. Again, the figure assumes a certain partitioning of the network that resulted in the performer behavior. Figure 9. Recursive Computation of UNI Link As noted in this document, the link performers may be thought of as the link management and traffic policing functions within a network. It provides the functional capability to control the availability of resources, and the allocation of those resources. In addition the link performer may also provide resource allocation for the purpose of connection restoration (e.g., protection switching or dynamic re- routing). The subnet performer may be thought of as providing a routing and cross-connect function within a network. It provides the functional Lin et al. Expires May 2001 18 UNI and NNI Operations and Parameters November 2000 capability to determine a path through a cross-connect. This cross- connect may be logically a subnetwork. Consequently, this subnetwork may be further partitioned into subnetworks connected by link connections, etc. At its lowest level, the subnetwork performer may be viewed as controlling the cross-connect matrix of a network element. As shown in Figure 9, the user UNI link From the service provider's perspective, the UNI link is composed of multiple links and subnetwork connections. These links include the user UNI A-end link, the service provider subnetwork connection, and the user UNI Z-end link. The service provider subnetwork may be composed of subnetwork connections and links across the service provider network (which makes up the NNI SNC). From the user's perspective, the UNI link is made up of three pieces: the A-end and Z-end link, and the service provider SNC. The user would not have visibility into the make-up of the service provider SNC, i.e., no visibility into the _colored_ connection points. 4.2 NNI Delete Connection Figure 10 illustrates the various processes (and the states) that participate in a NNI delete request operation. As with the NNI create processes, the delete process may involve multiple recursive and iterative performers interactions. Figure 10. High-Level NNI Delete Connection Operation The steps taken to delete a NNI subnetwork connection reverses those of the NNI create connection operation. Lin et al. Expires May 2001 19 UNI and NNI Operations and Parameters November 2000 In the case of a delete command, the above figure makes the following assumption: even though there may be errors during deletion of the connection, the user should be allowed to complete the delete request. This implies, e.g., if _deallocate NNI subnetwork connection_ process fails, a _request error_ is sent to the appropriate management system. The process continues to _delete NNI from directory entry_. If this stage fails, an error message may be sent to the management system. The result may be that the connection remains up, but the user will not have access, nor will they be _billed_ for the service. The service provider needs to handle the error condition. From the user's perspective, the connection has been deleted. Lin et al. Expires May 2001 20 UNI and NNI Operations and Parameters November 2000 4.3 NNI Modify Connection Figure 11 illustrates the various processes (and the states) that participate in a NNI modify request operation. Figure 11. High-Level NNI Modify Connection Operation In the case of the modify request, there may be potentially two types of modifications or changes to the connection: those that are disruptive (i.e., disrupts the UNI link), and those that are non- disruptive (i.e., in-service modify of UNI link attributes). Whether either or both are needed is for further study. For example, for the case of disruptive change of the UNI link, this may be realized via a create-delete combination of certain NNI links within the service provider domain. This may, e.g., occur if a user wants to request higher availability for the connection. As a result of this type of request, the service provider may need to determine a new route that exhibits the desired availability requirement. This new connection would be created within the service provider network, existing traffic would be switched onto this new connection, and the old connection would be deleted. Whether this action is referred to as a modify request or a create-delete request combination is for further discussion. In the above example, from the user's perspective, the user UNI A-end and Z-end connection point may be static during the modify process, while the NNI SNC may be changed. From the service provider's perspective, the link connections and Lin et al. Expires May 2001 21 UNI and NNI Operations and Parameters November 2000 the SNCs will change likely due to a create-delete request combination. 5. Parameters for UNI and NNI DCM As a result of the discussions above, and the type of information that may be required to be signaled for a connection operation, the following list of parameters are presented: Version ID This identifier provides the version of the UNI or NNI protocol. Version ID alone does not provide information on the backwards compatibility, and thus a new ID may be needed. It is expected that this is part of the protocol overhead. Backwards Compatibility ID This identifier provides information on the compatibility of previous UNI or NNI versions. It is expected that this is part of the protocol overhead. Message ID Unique identifier for the message applicable to the specific request or response type. This message ID is used to track the flow of the particular message communication from initiation to completion of the exchange. A-end name{8} Name of the A-end (or source) entity associated with a connection request. The name may also be the resource ID name. Z-end name Name of the Z-end (or destination) entity associated with a connection request. The name may also be the resource ID name. A-end User group ID This parameter is needed if the service used for supporting VPN provider offers, e.g., a VPN service, and service) identifies a unique name that is associated with a set of common resources accessible only by authorized users. Z-end User group ID This parameter is needed if the service used for supporting VPN provider offers, e.g., a VPN service, and service) identifies a unique name that is associated with a set of common resources accessible only by authorized users. ------------------- 8 There must be agreement on the use of A-end name, Z-end name and User group ID prior to any connection requests. This means an agreement on (a) use of user-side name or service provider-side name, (b) location of name/address translation. Lin et al. Expires May 2001 22 UNI and NNI Operations and Parameters November 2000 Contract ID This identifier refers to one (of several) pre-negotiated contract agreement between the user and service provider. This identifier would contain information sufficient to embed within it information about the type of services that a user may request. These constraints may include: availability, MTTR, SRLG, maximum delay requirements (e.g., no satellite links), etc. For example, the ID could be username:high-quality:avoid-Tokyo-area:do- not-use-satellite. Alternatively, the contract ID could be bronze service, gold service, or platinum service. Other routing constraints which are not embedded within the Ids may also be captured under this identifier. These information may be used during route determination to constrain the type of routes that may be set up. The content of this ID is service provider specific and may be defined by the service provider to allow embedding different semantics in the ID. Avoid name list This parameter provides a list of names used in UNI to constrain that may be used as input during route route determination) determination. Route determination uses these parameters to avoid traversing the specified names. The name list may constitute a list of the nodes. These names must be agreed between the user and service provider, and does not include topological information of the network. Include name list This parameter provides a list of names used in UNI to constrain that may be used as input during route Route determination) determination. Route determination uses these parameters and attempts to create a route that traverses the specified names. The name list may constitute a list of the nodes. These names must be agreed between the user and service provider, and does not include topological information of the network. Explicit route name list This parameter provides a list of names used in NNI to forward that unambiguously provides a route through explicit route as determined the network. The name list may constitute a by a _routing engine_) list of the nodes,. Lin et al. Expires May 2001 23 UNI and NNI Operations and Parameters November 2000 Service name{9} Name of the requested service. The service e.g., port ID, technology name should provide unique identification independent label) of the type of signal being requested as well as adequate identification to specify the link. For example, VC-4-4c:bidir, SDH:622Mbps:concat:bidir or PORT#7. Alternatively the service name may be AvailServID#9 (using the example network configuration shown in the previous section). If the service name is not adequate to identify a specific subchannel, a separate service name extension may be used to provide technology dependent information. A common format of the service name is needed in order for disparate NEs to communicate and discover these services automatically. Service name extension This parameter(s) extends the service name e.g., subchannel ID, parameter and specifies information technology dependent label regarding the requested service that may be retained for specific specific to a technology layer (each protocol implementations technology layer may have an additional that require technology extension parameter). This parameter may dependent information for specify the port ID, multiplexed signal the name) structure, etc. For example, Wavelength#3:E:D:C:B:A (where EDBCA is the SONET label format). This parameter is optional because it is technology dependent and implementation dependent. A common format of the service name is needed in order for disparate NEs to communicate and discover these services automatically. Schedule-duration This parameter is used when the service used when the service provider offers a scheduled service, and provider offers scheduled identifies the scheduling for a connection. services) This contains the start time of the connection, and the duration of the connection. Security This parameter is used to validate a user used to validate a user) request, and provides an identifier to encapsulate the security of the request. Security may also be provided via a secured network, such as using the IPsec. ------------------- 9 The resources used for the request may be chosen by either the user or the service provider. This must be agreed upon between the user and service provider prior to connection operations. For example, who chooses whether to use STS-1 #1 or STS-1 #2 for a particular connection request. Lin et al. Expires May 2001 24 UNI and NNI Operations and Parameters November 2000 User Connection ID This identifier represents a unique name Client handle) that is associated with a UNI-T A-end link, NNI-T SNC, and UNI-T Z-end link, which makes up the UNI-T link. Link ID This identifier represents a unique name may be NULL) that is associated with a NNI-T link allocated via the link performer for the specific layer network service. Depending on specific layer network, the link ID may not be needed, e.g., in a circuit network, after the cross-connects are set up, there is no need to indicate an ID _ ingress traffic from a particular port will be cross-connected directly to an egress port (or a drop port). For example, the link ID may use the AvailServID and a timestamp to provide a unique handle. Status code This parameter contains the response code to specific requests, and may include success or failure of the request, as well as state of the connection in response to a query. Note that depending on which request is issued, the status code may contain various information and may have multiple types of status code. However, from a requirements perspective, they are all status codes (i.e., no semantics and format is provided in this document). 5.1 Possible parameters for the UNI signaling protocol: The following section provides a list of possible parameters that may be used in the UNI signaling protocol. These parameters provide the basis for connection operations. UNI signaling requests may be initiated by (a) A-end user, (b) a third-party signaling agent, or (c) by the Z-end NNI agent. For create, the status code may simply provide success or failure of the request, or it may provide additional information such as incorrect ID, insufficient resources, cannot avoid specific name, etc. 5.1.1 UNI Create 5.1.1.1 UNI Create request parameters Version ID Backwards compatibility ID Message ID A-end user name Lin et al. Expires May 2001 25 UNI and NNI Operations and Parameters November 2000 A-end User group ID Z-end user name Z-end User group ID Contract ID Avoid name list{10} Include name list Service name Service name extension Schedule-duration Security 5.1.1.2 UNI Create response parameters Version ID Backwards compatibility ID Message ID User Connection ID (Client handle) Status code 5.1.2 UNI Delete For delete, the status code may simply provide success or failure of the request, or it may provide additional information such as incorrect ID, connection deleted (with errors reported to management system), etc. 5.1.2.1 UNI Delete request parameters Version ID Backwards compatibility ID Message ID User Connection ID (Client handle) Security 5.1.2.2 UNI Delete response parameters Version ID Backwards compatibility ID Message ID User Connection ID (Client handle) Status code 5.1.3 UNI Modify ------------------- 10 Avoid name list and Include name list are optional parameters. This list must be agreed between the user and the service provider, and does not expose the topological or resource information of the named list. It is used solely as constraints for route determination purposes. Lin et al. Expires May 2001 26 UNI and NNI Operations and Parameters November 2000 For modify, the status code may simply provide success or failure of the request, or it may provide additional information such as incorrect ID, insufficient resources, etc. 5.1.3.1 UNI Modify request parameters Version ID Backwards compatibility ID Message ID A-end user name A-end User group ID Z-end user name Z-end User group ID User Connection ID (Client handle) Contract ID Avoid name list Include name list Service name Service name extension Schedule-duration Security 5.1.3.2 UNI Modify response parameters Version ID Backwards compatibility ID Message ID User Connection ID (Client handle) Status code 5.1.4 UNI Query For query, the status code may provide information such as how many UNI links are set up by the requesting user, health of all those links or health of a particular link, usage information of the particular link, etc. 5.1.4.1 UNI Query Request parameters Version ID Backwards compatibility ID Message ID User Connection ID (Client handle) Security 5.1.4.2 UNI Query response parameters Version ID Backwards compatibility ID Message ID User Connection ID (Client handle) Lin et al. Expires May 2001 27 UNI and NNI Operations and Parameters November 2000 Status code 5.1.5 UNI Notification parameters Notification message is used to capture error conditions, where the user or service provider may need to report a condition. For this message, no response is expected, since for example in the service provider network, a fiber cut may bring down thousands of connections. The service provider will likely not expect (or want) to receive response from these thousands user link connections. Version ID Backwards compatibility ID Message ID User Connection ID (Client handle) Status code 5.2 Possible parameters for the NNI signaling protocol: The following section provides a list of possible parameters that may be used in the NNI signaling protocol. These parameters provide the basis for connection operations. 5.2.1 NNI Determine route This set of messages are used in determining an explicit route across the service provider network. Note that since a service provider may have multiple routing engines based on different constraints, e.g., OSPF, BGP, IS-IS, etc., the routing engine may be chosen based on certain user inputs (such as contract ID), or based on certain decisions made by the service provider. Upon determination of the explicit route, the routing engine responds with the appropriate route. If route determination is performed internally to an equipment, then this message may not be needed. However, in certain cases, explicit route may not be used. If explicit route is not used, then route determination may be based on hop-by-hop routing mechanisms. For determine route request, the status code may simply provide success or failure of the request, or it may provide additional information such as insufficient resources, no diversity (no SRLG diversity), cannot meet delay requirements as per contract, etc. 5.2.1.1 NNI Determine route request parameter Version ID Backwards compatibility ID Message ID A-end NNI name Z-end NNI name Lin et al. Expires May 2001 28 UNI and NNI Operations and Parameters November 2000 Contract ID{11} Avoid name list Include name list Service name Service name extension 5.2.1.2 NNI Determine route response parameter Version ID Backwards compatibility ID Message ID Link ID Explicit route list Status code 5.2.2 NNI Create Upon determination of the explicit route, the service provider nodes initiate creation of the subnetwork connection. If no explicit route were determined (i.e., using hop-by-hop routing), then each node determines its next hop based on some reachability information. In this case, instead of A-end and Z-end NNI name, the relevant information is the current NNI name (or local resource name) and the Z-end name. There are issues that need to be resolved when using hop-by-hop, such as preventing loops in the determined route. For create, the status code may simply provide success or failure of the request, or it may provide additional information such as insufficient resources, etc. 5.2.2.1 NNI Create request parameters Version ID Backwards compatibility ID Message ID A-end (or local resource) NNI name{12} Z-end NNI name{12} Service name Service name extension Explicit route (hop-by-hop, loose){12} ------------------- 11 For the route determination signaling message, the contract ID, avoid name list, and include name list provide the constraint for routing purposes. The contract ID, as per the terminology section, embeds within the availability, MTTR, SRLG, etc. information. 12 If explicit routing is used, then A-end and Z-end NNI names will likely not be needed. If explicit routing is not used, then A-end and Z-end NNI names will likely be needed. Lin et al. Expires May 2001 29 UNI and NNI Operations and Parameters November 2000 5.2.2.2 NNI Create response parameters Version ID Backwards compatibility ID Message ID Link ID Status code 5.2.3 NNI Delete For delete, the status code may simply provide success or failure of the request, or it may provide additional information such as connection deleted (with errors reported to management system), etc. 5.2.3.1 NNI Delete request parameters Version ID Backwards compatibility ID Message ID Link ID 5.2.3.2 NNI Delete response parameters Version ID Backwards compatibility ID Message ID Link ID Status code 5.2.4 NNI Modify For modify, the status code may simply provide success or failure of the request, or it may provide additional information such as insufficient resources, etc. 5.2.4.1 NNI Modify request parameters Version ID Backwards compatibility ID Message ID A-end NNI name Z-end NNI name Service name Service name extension Explicit route (hop-by-hop, loose) 5.2.4.2 NNI Modify response parameters Version ID Backwards compatibility ID Message ID Lin et al. Expires May 2001 30 UNI and NNI Operations and Parameters November 2000 Link ID Status code 5.2.5 NNI Query For query, the status code may provide information such as how many NNI links are set up at a particular node, health of all those links or health of a particular link, usage information of the particular link, etc. 5.2.5.1 NNI Query Request parameters Version ID Backwards compatibility ID Message ID NNI node name and/or Link ID 5.2.5.2 NNI Query response parameters Version ID Backwards compatibility ID Message ID Link ID Status code 5.2.6 NNI Notification parameters Notification message is used to capture error conditions, where a node may need to report a condition. For this message, no response is expected, since in the service provider network, a fiber cut may bring down thousands of connections. Version ID Backwards compatibility ID Message ID Link ID Status code ------------------- References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Lin et al. Expires May 2001 31 UNI and NNI Operations and Parameters November 2000 Author's Addresses Curtis Brownmiller, Worldcom Tel: 972-729-7171 Email: curtis.brownmiller@wcom.com Zhi-Wei Lin, Lucent Tel: 732-949-5141 Email: zwlin@lucent.com Olivier Duroyon, Alcatel Tel: 703-654-8605 Email: oduroyon@adn.alcatel.com Hirokazu Ishimatsu, Japan Telecom Tel: +81 3 5540 8493 Email: hirokazu@japan-telecom.co.jp Lin et al. Expires May 2001 32 UNI and NNI Operations and Parameters November 2000 Full Copyright Statement "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 33