IPO WG O. Aboul-Magd Internet Draft B. Jamoussi Document: draft-ietf-ipo-ason-01.txt S. Shew Category: Informational Nortel Networks Expires: June 2002 Gert Grammel Sergio Belotti Dimitri Papadimitriou Alcatel Nov., 2001 Automatic Switched Optical Network (ASON) Architecture and Its Related Protocols 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. 1. Abstract This draft is intended to describe the architecture for intelligent optical networks designed in ITU-T. This architecture is called the automatic switched optical networks (ASON). ASON is a control plane architecture that allows clients to request services from the optical network (server). ASON architecture and its generic automatic switched transport networks (ASTN) has been an active study area both at T1X1 and ITU [2,3]. The protocols that run over ASON interfaces are not specified in [2,3]. IP-based protocols like generalized MPLS (GMPLS) [4],can be considered such that the ASON/ASTN work can benefit from the protocols design work progressing at the IETF. In order to cross fertilize the discussion the basic concepts are described hereafter. Aboul-Magd Expires June 2002 1 Draft-ietf-ipo-ason-01.txt Nov. 2001 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [5]. 3. Introduction The existing transport networks provide SONET/SDH and WDM services whose connections are provisioned via network management protocols. This process is both slow (weeks to months) relative to the switching speed and costly to the network providers. An automatic switched optical network (ASON) is an optical/transport network that has dynamic connection capability. It encompasses SONET/SDH, wavelength, and potentially fiber connection services in both OEO and all-optical networks. There are a number of added values related to such a capability: - Traffic engineering of optical channels: Where bandwidth assignment is based on actual demand patterns. - Mesh network topologies and restoration: Mesh network topologies can in general be engineered for better utilization for a given demand matrix. Ring topologies might not be as efficient due to the asymmetry of traffic patterns. - Managed bandwidth to core IP network connectivity: A switched optical network can provide bandwidth and connectivity to an IP network in a dynamic manner compared to the relatively static service available today. - Introduction of new optical services: The availability of switched optical networks will facilitate the introduction of new services at the optical layer. Those services include bandwidth on demand and optical virtual private networks (OVPN). This draft describes the ASON architecture. ASON and its generic ASTN has been a topic of active discussion both at the T1X1 and ITU. The draft focuses on ASON control plane, its requirements, and related protocols. The ASON architecture at the ITU is discussed in two documents. The first document is G.8070 (previously known as G.astn)[3] describes network level, technology independent, requirements for the control plane of ASTN. The second document is G.8080 [2], and it specifies architecture and requirements for ASTN network as applicable to SDH transport networks and optical transport networks. 4. ASON/ASTN Architecture: An Overview ASON/ASTN architecture belongs to client-server models or the overlay network models as defined in [6]. The salient feature of Aboul-Magd Expires June 2002 2 Draft-ietf-ipo-ason-01.txt Nov. 2001 this model is the existence of well-recognized boundaries between client networks and provider domains. Client/provider separation is a direct recognition of today's networking realities where ownership of layer 3 and layer 1 equipment belongs to different organizations. This client/provider domain separation entails the running of different routing instants at each domain. Thus there is no need to share topology information between carriers and their clients. The ASON/ASTN is an architecture that allows for global connectivity as shown in Figure 1. Figure 1 illustrates user end systems connecting to a global ASTN/ASON network, which may be comprised of multiple provider domains. As an overlay model there is no trusted relationship between provider domains so the instantiated interfaces are E-NNIs. Within a provider domain, the instantiated interface between control plane entities is the I-NNI. +----+ UNI +-----------------+ UNI +----+ |user|--------| |--------|user| +----+ | global ASTN | +----+ +-----------------+ / \ / \ +----------+ +----------+ | ASTN | E-NNI | ASTN | |provider 1|---------|provider 2| +----------+ +----------+ / \ / \ / \ +-------------------+ | | | +--+ I-NNI +---+ | | | |--------| | | | +--+ +---+ | +-------------------+ Figure 1: ASON/ASTN Global Architecture As applied to optical networks, the ASON network interfaces are further shown in Figure 2. In this Figure all the components that can form part of ASON are shown. The architecture shown is intended to allow switching of optical network connections within the optical transport network under control of ASON signaling network. There are three separate planes involved in the network: - A transport plane (TP) - A control plane (CP) - A management plane (MP) +--------------------------+ +--------------+ | ASON Control Plane | | | | | | | Aboul-Magd Expires June 2002 3 Draft-ietf-ipo-ason-01.txt Nov. 2001 UNI | +------+ I-NNI +------+ E-NNI| +------+ | +------+ ------>| OCC |-------| OCC |-|----|----| OCC | | NMI| | | +------+ +------+ | | +------+ |<-->| | | ^ ^ | | ^ | | | +-----|--------------|-----+ +------|-------+ | | | CCI | | | | +-----|--------------|-----+ +------|-------+ | | | v v | | v | | | | +------+ +------+ | | +-----+ |<-->| | | | OXC | | OXC | | PI | | OXC | | NMI+------+ | | |-------| |-----------| | | | +------+ +------+ | | +-----+ | Management | Transport Plane | | | Plane +--------------------------+ +--------------+ OCC = Optical Network Controller UNI = User Network Interface CCI = Connection Control Interface OXC = Optical Cross Connect I-NNI = Internal Node to Node Interface E-NNI = External Node to Node Interface NMI = Network Management Interface PI = Physical Interface Figure 2: Automatic Switching Optical Network (ASON) Interfaces The transport plane contains the transport network elements (switches and links) that carry the entity that is switched, i.e. optical connections. End-to-end connections are setup within the transport plane under the control of the ASON control plane (CP). This draft is concerned with the CP part of the ASON architecture. Both the TP and MP are out of the scope of this draft. 5. ASON Control Plane: Requirements and Functional Architecture A well-designed control plane architecture should give service providers better control of their network, while providing faster and improved accuracy of circuit set-up. The control plane itself should be reliable, scalable, and efficient. It should also be sufficiently generic to support different technologies and differing business needs and different partitions of functions by vendors (i.e., different packaging of the control plane components). In summary, the control plane architecture should: - Be applicable to a variety of transport network technologies (e.g., SONET/SDH, OTN, PXC). In order to achieve this goal, it is essential that the architecture isolates technology dependent aspects from technology independent aspects, and address them separately. - Be sufficiently flexible to accommodate a range of different network scenarios. This goal may be achieved by partitioning the control plane into distinct components. This, allows vendors and service providers to decide the location of these components, and Aboul-Magd Expires June 2002 4 Draft-ietf-ipo-ason-01.txt Nov. 2001 also allows the service provider to decide the security and policy control of these components. The control plane shall support either switched connections (SC) of soft permenant connections (SPC) of basic connection capability in transport networks. These connection capabilities types are: - Uni-directional point-to-point connection - Bi-directional point-to-point connections - Uni-directional point-to-multipoint connections The components of the control plane architecture are illustrated in Figure 3. This Figure illustrates the control plane functions and their relationships. These entities can be packaged in different ways, depending upon the required functionality. +------------------------------------------------+ | | | +--------+ | | | PA | | | +--------+ | | | | | | | | +------+ +------+ +--------+ | X----| RTU |---------| RT |------| LRM |---X | +------+ +------+ +--------+ | | | / | | | | ----- | | | +------+ +------+/ +--------+ | | | PC | | CC |------| CAC | | | +------+ +------+ +--------+ | | | | +-----------------------X------------------------+ PA = Policing Agent RTU = Routing Table Update RT = Routing Table LRM = Link Resource Manager CC = Connection Controller CAC = Connection Admission Control PC = Protocol Controller X--- External Interface Figure 3: ASON/ASTN Control Plane Functional Components Directory service processes may be utilized by the control plane to provide a mapping/translation of names and association of these names between layer networks, sub-network domains (e.g., between provider domains), and user name translations. This process includes functions such as registration of a user within the ASON network (including association of a user name to an ASON name space). 5.1 Connection Controller Function (CC) The role of this function within the control plane is: Aboul-Magd Expires June 2002 5 Draft-ietf-ipo-ason-01.txt Nov. 2001 - The management and supervision of connection set-ups; - The management and supervision of connection releases; - The modification of connection parameters for existing connections. In response to a connection request the function must co-ordinate the interrogation of the route table, requests to the call admission control function, and updating the status of connection points. 5.2 Route Table Function (RT) The route table function consists of a list of reachable destinations and for each destination a recommended egress link. The role of the route table function is to respond to the request from the connection controller for the egress link for a particular destination. Note that there are likely to be significant differences between I- NNI and E-NNI RT functions. Further, the reachability may also be a function of the policy and routing constraints. 5.3 Route Table Update Function (RTU) Information stored in routing tables may be manually entered and updated, as in the case of static routing. However, networks may also automatically generate and maintain route tables and distribute them throughout the network (at least within a domain). The role of the route table update function is to: - Relay the contents of a local route table for a sub-network to all of its immediate neighbors; - Receive the route tables from immediate neighboring sub-network controllers and update local route table to reflect all of the destinations it can reach via its neighbors. 5.4 Connection Admission Control Function (CAC) The role of this function is to decide if there is sufficient free resource on a link to allow a new connection. If there is the call admission control may allow a connection request to proceed. If it is not allowed to proceed then the connection admission control informs the connection controller to either find a new route or, where none is available, notify the originator of the connection request that the request has been refused. In principle there is a connection admission control function associated with every resource manager. Connection admission control can also be decided based on prioritization or on other policy decisions. CAC policies are outside the scope of standardization. The connection admission control interacts with: Aboul-Magd Expires June 2002 6 Draft-ietf-ipo-ason-01.txt Nov. 2001 - The connection controller from which it receives connection requests; - The link resource manager. 5.5 Link Resource Manager Function (LRM) The role of this function is to keep track of the way link resources are allocated to connections. The two primary resources that are held by the link resource manager are capacity and connection identifiers. The link resource manager records the capacity as seen by the connection point group agent or access group agent and controls the allocation of capacity to connections when requested as part of the connection set-up process. The link resource manager interacts with: - The connection admission control function from which it receives requests for link resources; - The policing function for the setting and enforcement of policing parameters for a connection; - The connection controller that is informed by the link resource manager that a connection has been admitted or released. The behaviour of the link resource manager is dependent upon the type of connection involved and the policies in force for reservation and priority. As such the behaviour is technology dependent. In the case of circuit switching resource management is simple since the allocation of capacity is automatic when a link connection is connected to a connection. The link resource manager function looks after label mappings and variable capacity connections. 5.6 Connection Point Status Function (CPS) The role of this function is to provide the connection controller with visibility of the status of all the connection points on the boundary of the subnetwork. The underlying CTP or TTP agents provide the connection point status function. The status is the state of the connection point as it proceeds through connection set- up and release. 5.7 Policing Agent Function (PA) The role of this function is to check that a connection is sending traffic according to the parameters agreed at connection set-up or as a result of a modification request. Where a connection violates the agreed parameters then the policing agent may instigate measures to correct the situation. Note: this is not needed for a CBR transport layer network. PA relates to the incoming connection only. 5.8 Protocol Controller Function (PC) Aboul-Magd Expires June 2002 7 Draft-ietf-ipo-ason-01.txt Nov. 2001 The role of the protocol controller is to provide reliable transfer of control messages across the network by means of a defined interface. This permits messages to be tracked and to ensure expected responses are received or that an exception is reported to the originator. Under normal circumstances signaling primitives are passed between the connection controller and the protocol controller within a sub- network controller. The protocol controller is semantically transparent to the messaging primitives as these result in external protocol messages and vice versa. Signaling messages are passed between protocol controllers in different sub-network controllers. Protocol controllers are used to transfer the following information Route table update messages via a route table update protocol controller; - Link resource manager messages (where appropriate as in available bit rate connections) via a link resource manager protocol controller; - Connection control messages via a connection controller protocol controller. In addition, different protocol controllers may be implemented for the following, I-NNI, E-NNI, and UNI. In the case of a Ÿfabric controller÷ there is an additional interface, the CCI, between the underlying fabric and the controller. This, in a single network element, is not subject to standardization. 6. ASON Control Plane: External Interfaces and Protocols The ASON CP as shown in Figure 2 defines a set of interfaces: - User-Network Interface (UNI): UNI runs between the optical client and the network. - Internal Node-to-Node Interface (I-NNI): I-NNI defines the interface between the signaling network elements, i.e. OCC within the switched optical network. - External Node-to-Node Interface (E-NNI): E-NNI defines the interface between ASON control planes in different administration domains. - Connection Control Interface (CCI): The CCI defines the interface between ASON signaling element, i.e. OCC and the transport network element, i.e. the cross connect. The different ASON interfaces are described in the next few sections. Candidate protocols for use at the different interfaces are also discussed. Aboul-Magd Expires June 2002 8 Draft-ietf-ipo-ason-01.txt Nov. 2001 6.1 ASON User-Network Interface ASON UNI allows ASON client to perform a number of functions including: - Connection Create: Allows the clients to signal to the network to create a new connection with specified attributes. Those attributes might include bandwidth, protection, restoration, and diversity. - Connection Delete: Allows ASON clients to signal to the network the need to delete an already existing connection. - Connection Modify: Allows ASON clients to signal to the network the need to modify one or more attribute for an already existing connection. - Status Enquiry: Allows ASON clients to enquire the status of an already existing connection. Other functions that might be performed at the ASON UNI are, client registration, address resolution, neighbor and service discovery. Those functions could be automated or manually configured between the network and its clients. Client registration and address resolution are tightly coupled to the optical network address scheme. Requirements for optical network addresses and client names are outlined in [7]. In general the client name (or identification) domain and optical address domain are decoupled. The client id should be globally unique to allow for the establishment of end-to-end connections that encompass multiple administration domains. For security, it is required that the nodal addresses used for routing within an optical domain do not cross network boundaries. The notion of closed user groups should also be included in ASON addressing to allow for the offering of OVPN services. Address registration and resolution usually involves some kind of a directory service. The client uses the registration process to register his identification with the provider network for a particular user group or groups. Address resolution involves the process of translating client names to network addresses. Address resolution can be performed at clients, edge network element, or at every administrative boundary entry. It could involves authentication and policy look up to make sure that a client has the necessary credentials to join a user group. ASON UNI realization requires the implementation of a signaling protocol with sufficient capabilities to satisfy UNI functions. Both LDP [8] and RSVP-TE [9] have been extended to be used the signaling protocol across the ASON UNI. The extensions involve the definition of the necessary TLVs or objects to be used for signaling connection attributes specific to the optical layer. New messages are also Aboul-Magd Expires June 2002 9 Draft-ietf-ipo-ason-01.txt Nov. 2001 defined to allow for connection status enquiry. The Optical Internetworking Forum (OIF) has adopted both protocols in its UNI 1.0 specifications [10]. 6.2 ASON Internal Node-to-Node Interface The I-NNI defines the interface between adjacent optical connection controls (OCC) in the same network. There are two main aspects of I- NNI. Those are signaling and routing. Path selection and setup through the optical network requires a signaling protocol. Transport networks typically utilize explicit routing, where path selection can be done either by operator or software scheduling tools in management systems. IN ASON, end-to-end optical channels (connections) are requested with certain constraints. Path selection for a connection request should employ constrained routing algorithms that balance multiple objectives: - Conform to constraints such as physical diversity, etc. - Load balancing of network traffic to achieve the best utilization of network resources. - Follow policy decisions on routing such as preferred routes. To facilitate the automation of the optical connection setup, nodes in the optical network must have an updated view of its adjacencies and of the utilization levels at the various links of the network. This updated view is sometime referred to as state information. State information dissemination is defined as the manner in which local physical resource information is disseminated throughout the network. First the local physical resource map is summarized into logical link information according to link attributes. This information can then be distributed to the different nodes in the network using the control plane transport network IGP. ASON I-NNI could be based on two key protocols, IP and MPLS. Since MPLS employs the principle of separation between the control and the forward planes, its extension to support I-NNI signaling is feasible. Generalized MPLS [4] defines MPLS extensions to suit types of label switching other than the in-packet label. Those other types include, time slot switching, wavelength and waveband switching, and position switching between fibers. Both CR-LDP [11] and RSVP-TE [12] have been extended to allow for the request and the binding of generalized labels. With generalized MPLS, a label switched path (LSP) is established with the appropriate encoding type (e.g. SONET, wavelength, etc.). LSP establishment takes into account specific characteristics that belong to a particular technology. MPLS traffic engineering requires the availability of routing protocols that are capable of summarizing link state information in their databases. Extensions to IP routing protocols, OSPF and IS-IS, Aboul-Magd Expires June 2002 10 Draft-ietf-ipo-ason-01.txt Nov. 2001 in support of link state information for generalized MPLS are described in [13, 14]. 6.3 ASON External Node-to-Node Interface E-NNI is an inter-domain interface for use between ASON networks that are under different network administrations. It is similar to the UNI interface with some routing functions to allow for the exchange of reachability information between different domains. BGP is an IP based protocol that could be used to summarize reachability information between different ASON domains in the same manner as it has been in use today for IP networks. 6.4 ASON Connection Control Interface CCI defines the interface between the ASON signaling element (OCC) and the transport network elements. Connection control information is passed over this interface to establish connections between the ports of the optical transport switch. The CCI is included as part of ASON control plane because it enables switches of various capacities and internal complexities to be part of an ASON node. The protocol running across the CCI must support two essential functions: - Adding and deletion of connections. - Query of port status of the switch. General Switch Management Protocol (GSMP) [15] fits CCI requirements. GSMP is a general-purpose protocol that allows a controller to establish and release connections across a switch. GSMP is well suited for network architectures that employs label swapping in the forwarding plane, e.g. ATM, FR, and MPLS. This property makes GSMP a good fit for generalized label as defined by generalized MPLS. GSMP extensions for generalized MPLS are yet to be worked out. 7. ASON/ASTN CP Transport Network (signaling Network) In this section, we detail some architectural considerations for the makeup of the transport network that is used to transport the control plane information. For circuit-based networks, the ability to have an independent transport network for message transportation is an important requirement. The control network represents the transport infrastructure for control traffic, and can be either in-band or out-of-band. An implication of this is that the control plane may be supported by a different physical topology from that of the underlying ASON. There are fundamental requirements that control networks must satisfy in order to assure that control plane data can be transported in a reliable and efficient manner. In the event of control plane failure Aboul-Magd Expires June 2002 11 Draft-ietf-ipo-ason-01.txt Nov. 2001 (for example, communications channel or control entity failure), while new connection operations will not be accepted, existing connections will not be dropped. Control network failure would still allow dissemination of the failure event to a management system for maintenance purposes. This implies a need for separate notifications and status codes for the control plane and ASON. Additional procedures may also be required for control plane failure recovery. It is recognized that the inter-working of the control networks is the first step towards control plane inter-working. To maintain a certain level of ease, it's desirable to have a common control network for different domains/sub-networks or types of network. Typically, control plane and transport functions may co-exist in a network element. However, this may not be true in the case of a third party control. This situation needs further study. Furthermore, addressing issues in the control plane vis-Ç-vis the transport network is also for further study. ASON CP transport network requirements includes: - Control plane message transport should be secure. This requirement stems from the fact that the information exchanged over the control plane is service-provider specific and security is of utmost importance. - Control message transport reliability has to be guaranteed in almost all situations, even during what might be considered catastrophic failure scenarios of the controlled network. - The control traffic transport performance affects connection management performance. Connection service performance largely depends on its message transport. Time sensitive operations, such as protection switching, may need certain QoS guarantees. Furthermore, a certain level of survivability of the message transport should be provided in case of control network failure. - The control network needs to be both upward and downward scalable in order for the control plane to be scalable. Downward scalability may be envisioned where the ASON network offers significant static connections, reducing the need for an extended control network. - The control plane protocols shall not assume that the signaling network topology is identical to that of the transport network. The control plane protocols MUST operate over a variety of signaling network topologies. Given the above requirements, it is critical that the maintenance of the control network itself not pose a problem to service providers. As a corollary this means that configuration-intensive operations should be avoided for the control network. Aboul-Magd Expires June 2002 12 Draft-ietf-ipo-ason-01.txt Nov. 2001 Common channel signaling links are associated with user channels in the following ways: - Associated, whereby signaling messages related to traffic between two network elements are transferred over signalling links that directly connect the two network elements - Non-associated, whereby signaling messages between two network elements A and B are routed over several signalling links, whilst traffic signals are routed directly between A and B. The signalling links used may vary with time and network conditions - Quasi-associated, whereby signaling messages between nodes A and B follow a predetermined routeing path over several signalling links whilst the traffic channels are routed directly between A and B. Associated signaling may be used where the number of traffic channels between two network elements is large, thereby allowing a single signaling channel to be shared amongst a large number of traffic channels. Quasi-associated signaling may be used to improve resiliency. For example consider a signaling channel that has failure mechanisms independent of the traffic channels. Failure of the signaling channel will result in loss of signaling capability for all traffic channels even if all the traffic channels are still functional. Quasi- associated signaling mitigates against this by employing alternative signaling routes. In other words the signaling network must be designed such that failure of a signaling link shall not affect the traffic channels associated with that signaling channel. 8. Transport Network Survivability and Protection This section describes the strategies that can be used to maintain the integrity of an existing call in the event of failures within the transport network. The terms ŸProtection÷ (replacement of a failed resource with a pre-assigned standby) and ŸRestoration÷ (replacement of a failed resource by re-routing using spare capacity) are used to classify these techniques. In general, protection actions complete in the tens of millisecond range, while restoration actions normally complete in times ranging from hundreds of milliseconds to up to a few seconds The ASON control plane provides a network operator with the ability to offer a user calls with a selectable class-of-service (CoS), (e.g., availability, duration of interruptions, Errored Seconds, etc). Protection and restoration are mechanisms (used by the network) to support the CoS requested by the user. The selection of the survivability mechanism (protection, restoration or none) for a particular connection that supports a call will be based on; the policy of the network operator, the topology of the network and the capability of the equipment deployed. Different survivability mechanisms may be used on the connections that are concatenated to provide a call. If a call transits the network of more than one operator then each network should be responsible for the Aboul-Magd Expires June 2002 13 Draft-ietf-ipo-ason-01.txt Nov. 2001 survivability of the transit connections. Connection requests at the UNI or E-NNI will contain only the requested CoS, not an explicit protection or restoration type. The protection or restoration of a connection may be invoked or temporarily disabled by a command from the management plane. These commands may be used to allow scheduled maintenance activities to be performed. They may also be used to override the automatic operations under some exceptional failure conditions. The Protection or Restoration mechanism should: - Be independent of, and support any, client type (e.g., IP, ATM, SDH, Ethernet). - Provide scalability to accommodate a catastrophic failure in a server layer, such as a fiber cable cut, which impacts a large number client layer connections that need to be restored simultaneously and rapidly. - Utilize a robust and efficient signaling mechanism, which remains functional even after a failure in the transport or signaling network. - Not rely on functions which are non-time critical to initiate protection or restoration actions. Therefore consideration should be given to protection or restoration schemes that do not depend on fault localization. 10. Relationship to GMPLS Architecture The relationship between ASON/ASTN control plane architecture and GMPLS-based protocols is established in section 6, where it has been shown how the different GMPLS protocol could be used for the realization of the different ASON/ASTN external interfaces. Recently, a GMPLS architecture [16] has been introduced. It is important to note that there is no real conflict between GMPLS architecture and the network architecture presented in this draft. ASON/ASTN provides a functional architecture of a control plane that allows the establishment of switched paths in optical networks. It provides the set of external interfaces that are necessary for the ASTN/ASON network to have a global reach. It does that, however, in a protocol independent fashion that can be realized in a different ways provided that its requirements are satisfied. The GMPLS architecture focuses more on the applications of GMPLS- defined protocols, e.g. CR-LDP for the setup of generalized LSP (GLSP) at the different interfaces of the network, e.g. I-NNI, UNI, etc. It does that in a more comprehensible way than what is described in section 6 of this draft. 11. Other ASON/ASTN Related ITU Activities Aboul-Magd Expires June 2002 14 Draft-ietf-ipo-ason-01.txt Nov. 2001 This section describes other activities that are currently underway at the ITU and are related to ASON/ASTN architecture. 11.1 Common Equipment Management (G.cemr) G.cemr [17] recommendation specifies those Equipment Management Functions (EMF) requirements that are common for SDH and OTN. The equipment management function (EMF) provides the means through which a Network Element Level manager manages the Network Element Function (NEF). These kind of functions are not detailed in the current GMPLS work since it is focused on control plane related aspects. Network Management aspects are subjects of other working groups in IETF such as OPS WG. 11.1.1 MPLS solution Element Manager functions are not part of the control plane specifications in GMPLS. 11.1.2 Requirements - Network management applications shall perform, Fault, Configuration, Accounting, Performance and Service Management (FCAPS). - Path setup can be triggered by means of a Network Management System using control plane mechanisms - For path setup control plane and Network management systems shall cooperate to allow path provisioning by network management as well as provisioning using the control plane. 11.2 Data Communications Network (G.7712/Y.1703) In [18] the various functions constituting a telecommunications network can be classified into two broad functional groups. One is the transport functional group which transfers any telecommunications information from one point to another point(s). The other is the control functional group which realizes various ancillary services and operations and maintenance functions. The Data Communications Network (DCN) provides transport for the applications associated with the control functional group. Examples of such applications that are transported by the DCN are: transport network operations/management applications, DCN operations/management applications, Automatic Switched Transport Services (ASTN) control plane applications, voice communications, etc. The IP-based DCN provides Layer 1 (physical), Layer 2 (data-link) and Layer 3 (network) functionality and consists of routing/switching functionality interconnected via links. These links can be implemented over various interfaces, including WAN interfaces, LAN interfaces, and ECCs. Aboul-Magd Expires June 2002 15 Draft-ietf-ipo-ason-01.txt Nov. 2001 This recommendation provides the architecture requirements for an IP-based DCN, the requirements for inter-working between an IP-based DCN and an OSI-based DCN, and the IP-based DCN interface specifications. 11.2.1 GMPLS solution Since in GMPLS the signaling and management plane are independent from each other, different kinds of networks can be used for both tasks. Today GMPLS itself can be managed by the use of GMPLS MIB (draft-nadeau-mpls-gmpls-te-mib-00.txt and referenced). In the view of GMPLS each node is capable to process signaling and routing messages whereby the topology of the transport network and the control-plane network are the same. 11.2.2 Requirements - The management and signaling functions shall be decoupled from each other - the DCN shall support in-fiber-in-band, in-fiber-out-of- band and out-of-fiber/out-of-band signaling for any kind of technology - DCN shall be dimensioned to support fast restoration by providing fast transport of restoration messages. - DCN shall be IP based and support IP addressing. - IP routing mechanisms (OSPF, IS-IS) shall be used 11.3 Distributed Connection Management (G.7713/Y.1704) G.7713/Y.1704 [19] Recommendation covers the areas associated with the signalling aspects of automatic switched transport network, such as attribute specifications, the message sets, the interface requirements, the DCM state diagrams, and the interworking functions for the distributed connection management 11.3.1 GMPLS solution In GMPLS a permanent communication between the Network devices is established which is anyhow necessary to exchange reachability and traffic-engineering information (e.g. routing protocol provides reachability and TE attributes information). Link bundling plays a key role by augmenting the scalability of the routing protocol. A user device or a management station can optionally trigger a connection setup and initiates a control plane action. 1. In a first phase the edge device (where the Trail Termination is located) has to determine the route (trail) either by a route calculation (e.g. explicit route computation through C- SPF) or by receiving a pre-calculated route from an external device e.g. a Traffic Engineering Tool. 2. Then it signals the trail request to the involved nodes across the network, reserving the bandwidth without allocating it. Aboul-Magd Expires June 2002 16 Draft-ietf-ipo-ason-01.txt Nov. 2001 3. When bandwidth reservation has been performed the trail is implemented. Some optimizations have also been added in order to speed up the process of implementing the connection. The full procedure is explained in more detail in draft-ietf-mpls-generalized-signaling- 05.txt. 11.3.2 Requirements GMPLS control plane components could be applied to ASTN to achieve a distributed connection control taking into account draft-ietf-mpls- generalized-signaling-05.txt. 11.4 Generalized Automatic Discovery (G.7714/Y.1705) G.7714/Y.1705 [20] describes the specifications for automatic discovery (referred to as auto-discovery) to aid distributed connection management (DCM) and routing in the context of automatically switched transport networks (ASTN/ASON). In this recommendation, three major instances of discovery are addressed, (a) adjacency discovery (b) neighbor discovery (c) service discovery. In addition, the results of neighbor discovery are also used for establishing logical adjacencies between nodes at the control plane. 11.4.1 Adjacency Discovery Adjacency discovery is described as the process of verifying physical connectivity between two ports on adjacent network elements over a specific physical layer. Depending on the physical packaging of the functions within a network element, two types of associations need to be discovered as part of adjacency discovery. 11.4.2 GMPLS Solution Optical Link Interface (OLI) concept and requirement are proposed in conjunction with LMP-WDM protocol to cover the functions provided by adjacency discovery. From the GMPLS perspective, information exchange occurs between a Ÿpassive÷ and an Ÿactive÷ element, such as between a DWDM (OLS) system and an OXC. Ongoing work with ITU referred to as G.VBI (Virtual Backplane Interface) will complete the picture. 11.4.3 Requirements - Adjacency discovery should be provided through a simple protocol mechanism for reporting the health and properties of OLSs based on a well-defined set of parameters. - It should be extensible so that we can start with a set of most-needed parameters initially, and be able to extend later by adding new parameter types and new parameters within a type. Aboul-Magd Expires June 2002 17 Draft-ietf-ipo-ason-01.txt Nov. 2001 - The initial focus is on SONET and SDH equipment. However, the OLI must be extensible to support other types of equipment such as Ethernet and G.709 OTN. - The adjacency must be reliable, not only assume a one-to-one relationship between OLS and client i.e., an OLS client will most likely be attached to multiple different OLSs, and a single OLS may have multiple different clients at a single location. 11.4.4 Neighbor Discovery [20] Recommendation provides the requirements and message sets for the automatic neighbor for the User-to-Network Interface (UNI), Internal Node-to-Node Interface (I-NNI), External Node-to-Node Interface (E-NNI) and Physical Interface (PI). The requirements in this Recommendation specify the discovery process across these interfaces that aid automated connection management. 11.4.5 GMPLS solution MPLS is based on an IP-based control plane incorporating protocols defined for routing and neighbor discovery defined in OSPF and IS- IS. To achieve a single control plane across multiple technology layers a single method for neighbor discovery and routing is mandatory. LMP extensions for neighbor discovery have solved the Ÿpotential÷ problem of the usage of a routing protocol at the UNI (when considering for instance OIF UNI 1.0 specification) 11.4.6 Requirements - Neighbor Discovery shall be used to detect and maintain Node adjacencies. For this the mechanisms already defined at the IETF for OSPF and IS-IS shall be used. - Topology information and resource information shall be decoupled. While topology information remains unchanged, resource utilization can change dynamically when setting up new path. To support this concept the links between two adjacent nodes shall be bundled. In case of any single link failure within the bundle, the topology information remains stable while the capacity information may change. - The control plane shall detect changes in the resources and enable timely reaction if established path or network resources are affected by this change. 11.4.7 Service Discovery [20] provides the requirements and message sets for the automatic service discovery for the User-to-Network Interface (UNI), Internal Node-to-Node Interface (I-NNI), External Node-to-Node Interface (E- NNI) and Physical Interface (PI). The requirements in this Recommendation specifies the discovery process across these interfaces that aid automated connection management. Aboul-Magd Expires June 2002 18 Draft-ietf-ipo-ason-01.txt Nov. 2001 11.4.8 GMPLS solution GMPLS focuses on intra-domain implementation on which OIF based itËs UNI specification. OIF-UNI GMPLS profile can be considered when discussing about UNI implementations. Extensions of LMP enables the exchange of service discovery information at the UNI 1.0 specification. 11.4.9 Requirements - Service discovery mechanisms shall be aligned with the mechanisms provided by GMPLS such that a seamless integration of UNI and NNI can be supported. 11.5 OTN routing (G.rtg) A first outline has been presented during the last ITU Q14/SG15 meeting, however one doesnËt expect to see a more complete specification prior to Mid-2002. 11.5.1 GMPLS solution GMPLS is supposed to be based on OSPF/IS-IS routing mechanisms and more explicitly to the traffic engineering extensions of these protocols like e.g. CSPF. See also: Ÿdraft-kompella-ospf-gmpls- extensions-01.txt OSPF Extensions in Support of Generalized MPLS÷ and Ÿdraft-ietf-isis-gmpls-extensions-02.txt IS-IS Extensions in Support of Generalized MPLS÷. Today on-going work related to GMPLS/BGP has started as well in order to cover inter-domain routing specification for non-packet based networks (such as draft-parent- optical-bgp-00.txt) It allows also to use explicit or implicit routing. 11.5.2 Requirements - Support of explicit and implicit routing - Support of OSPF and ISIS routing protocols for intra-domain and subsequently BGP for inter-domain routing - Support of constrained based routing in order to e.g. Conform to constraints such as physical diversity, Achieve traffic engineering objectives in the transport network. Examples are to adhere to operator policies on routing such as preferred routes or to conform to network specific constraints 11.6 OTN Connection Admission Control (G.cac) Connection admission control (CAC) is necessary for authentication of the user and controlling access to network resources. CAC shall be provided as part of the control plane functionality. It is the role of the CAC function to determine if there is sufficient free resource Aboul-Magd Expires June 2002 19 Draft-ietf-ipo-ason-01.txt Nov. 2001 available to allow a new connection. € If there is, the CAC may permit the connection request to proceed, alternatively, if there is not, it shall notify the originator of the connection request that the request has been denied. Connections may be denied on the basis of available free capacity or alternatively on the basis of prioritisation. CAC policies are outside the scope of standardisation.÷ 11.6.1 GMPLS solution Call admission control in the sense of authentication and access control is not explicitly addressed in GMPLS since a trusted relation in a single operator, multi-vendor network is assumed. The work related to connection admission is performed e.g. in OIF. Related issues like security of signaling protocols is already included in RSVP-TE and CR-LDP. However, if a given LSP can not be established through the network (for reasons as diverse as resource unavailability, overbooking, control-plane congestion, etc.) it is simply rejected. 11.6.2 Requirements None 11.7 OTN Link Management (G.lm) No ITU-T contribution available prior to October 2001. 11.7.1 GMPLS solution The Link Management Protocol defined in draft-ietf-ccamp-lmp-00.txt is used to manage the resources available between two nodes and to check the connections. It is closely related to the unnumbered interface and bundling concepts described in Ÿdraft-kompella-mpls- bundle-05.txt Link Bundling in MPLS Traffic Engineering÷. 11.7.2 Requirements - Link management shall form a consistent network level resource view between adjacent nodes. - The use of link management shall decouple resource information from topology information which is bound to the bundling concept. - LMP as under definition in IETF (draft-ietf-ccamp-lmp-00.txt) shall be considered for G.lm. 12. Security Considerations This draft does not introduce any unknown security issues. Aboul-Magd Expires June 2002 20 Draft-ietf-ipo-ason-01.txt Nov. 2001 13. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Mayer, M. Ed., "Requirements for Automatic Switched Transport Networks (ASTN)", ITU G.8070/Y.1301, V1.0, May 2001. 3 M. Mayer, Ed., "Architecture for Automatic Switched Optical Networks (ASON)", ITU G.8080/Y1304, V1.0, October 2001 4 Ashwood-Smith, P. et. al., "Generalized MPLS- Signaling Functional Description", draft-ietf-mpls-generalized-signaling- 04.txt, work in progress, May. 2001 5 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 6 Rajagopalan, B. et. al., "IP over Optical Networks: A Framework", draft-many-ipo-optical-framework-03.txt, work in progress, March. 2001 7 Lazar, M. et. al., "Alternate Addressing Proposal", OIF Contribution, OIF2001.21, January 2001. 8 Aboul-Magd, O. et. al., "LDP Extensions for Optical User Network Interface (O-UNI) Signaling", draft-ietf-mpls-ldp-uni-optical- 01.txt, work in progress, July 2001. 9 Yu, J., et. al., "RSVP Extensions in Support of OIF Optical UNI Signaling", draft-yu-mpls-rsvp-oif-uni-00.txt, work in progress, Dec. 2000. 10 Rajagopalan, B. Editor, "User Network Interface (UNI) 1.0 Signaling Specifications", OIF Contribution, OIF2000.125.5, June 2001 11 Ashoowd-Smith, P. et. al., "Generalized MPLS Signaling: CR-LDP Extensions", draft-ietf-mpls-generalized-cr-ldp-03.txt, work in progress, May 2001 12 Ashwood-Smith, P. et. al., "Generalized MPLS Signaling: RSVP-TE Extensions", draft-ietf-mpls-generalized-rsvp-te-03.txt, work in progress, May 2000. 13 Kompella, K. et. al., "IS-IS Extensions in Support of Generalized MPLS", draft-ietf-isis-gmpls-extensions-01.txt, work in progress, Nov. 2000. Aboul-Magd Expires June 2002 21 Draft-ietf-ipo-ason-01.txt Nov. 2001 14 Kompella, K. et. al., "OSPF Extensions in Support of Generalized MPLS", draft-kompella-ospf-gmpls-extensions-01.txt, work in progress, Nov. 2000. 15 Doria, A. et. al., "Generalized Switch Management Protocol V3", draft-ietf-gsmp-08.txt, work in progress, Nov. 2000. 16 Mannie, E., Ed., "Generalized Multi-Protocol Lable Switching (GMPLS) Architecture" draft-ietf-ccamp-gmpls-architecture-00.txt, work in progress, June 2001. 17 Draft New RecommendationG.cemr, Common Equipment Management Function Requirements, ITU, June 2001 18 C. Daloia, Ed., "Architecture and Specification of Data Communication Network", ITU G.7712/Y.1703, October 2001 19 Z. Lin, Ed., "Distributed Call and Connection Management", ITU G.7713/Y.1704, October 2001 20 S. Sankaranarayanan, Ed., "Generalized Automatic Discovery Techniques", ITU G.7714/Y.1705, October 2001. 14. Author's Addresses Osama Aboul-Magd Nortel Networks P.O. Box 3511, Station C Ottawa, Ontario, Canada K1Y-4H7 Phone: 613-763-5827 E.mail: Osama@nortelnetworks.com Bilel Jamoussi Nortel Networks 600 Technology Park Drive Billerica, MA 01821, USA Phone: 978-288-4506 Email: jamoussi@nortelnetworks.com Stephen Shew Nortel Networks P.O. Box 3511, Station C Ottawa, Ontario, Canada K1Y-4H7 Phone: 613-763-2462 Email: sdshew@nortelnetworks.com Gert Grammel Aboul-Magd Expires June 2002 22 Draft-ietf-ipo-ason-01.txt Nov. 2001 Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-4453 Email: gert.grammel@netit.alcatel.it Sergio Belotti Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7060 Email: sergio.belotti@netit.alcatel.it Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be Full Copyright Statement "Copyright (C) The Internet Society (date). 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 implmentation 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 Aboul-Magd Expires June 2002 23