Internet DRAFT - draft-xu-ccamp-gmpls-arch-intra-domain

draft-xu-ccamp-gmpls-arch-intra-domain





Network Working Group                                     
Internet Draft			
Expiration Date: September 2001	


                              Yangguang Xu            Yong Xue
                              Eve Varma               UUNet/WorldCom
                              Ramesh Nagarjan         
                              Lucent                  Curtis Brownmiller
                                                      WorldCom
                              Dianiel O. Awduche
                              Movaz                   John Eaves
                                                      Tycom
                              Osama Aboul-Magd        
                              Michael Mayer           Hirokazu Ishimatsu
                              Nortel                  Japan Telecom

                              Rudy Hoebeke            Guangzhi Li
                              Alcatel                 AT&T
                                                                               
                              Raj Jain
                              Nayna

                                                          
                                                      March  2001


                  Intra-Domain GMPLS Control Plane Architecture 
                  for Automatically Switched Transport Network

                  draft-xu-ccamp-gmpls-arch-intra-domain-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.

   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."





Y. Xu et al.                                                      Page [1]

Internet Draft          GMPLS Architecture for ASTN               March 2001
   

   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

   Many solutions have been proposed to enable Automatically Switched 
   Transport Networks (ASTN). This document describes an IP/MPLS based intra-
   domain control plane architecture that can be applied to different circuit 
   switching technologies (including OTN, PDH and SONET/SDH). This memo includes 
   generic procedures, key concepts, and technical considerations for the common 
   control plane architecture. It is intended to accentuate understanding of the 
   application domains, create architectural alignment, and serve as guide for 
   protocol engineering.

   

Table of Contents


    1       Specification  ......................................  3 
    2       Acronyms   ..........................................  4
    3       Introduction to Generalized MPLS Control Plan  ......  4 
    4       Architecture Overview  ..............................  6
    4.1     System Components  ..................................  6
    4.2     Network Overview  ...................................  8
    4.3     Control Plane Network and Requirements   ............  9
    5       Detailed Architectural Considerations  ..............  11
    5.1     NE Level Resource Discovery  ........................  11
    5.1.1   NE Level Resource Table  ............................  11
    5.1.2   Resource Discovery Stages  ..........................  12
    5.2     State Information Dissemination  ....................  13
    5.2.1   Logical Link/Bundle  ................................  13
    5.2.2   Link State Information   ............................  14
    5.2.3   Link State Dissemination Mechanisms  ................  15
    5.2.4   Flooding Control  ...................................  15
    5.3     Path Selection  .....................................  16
    5.3.1   Routing Constraints in ASTN  ........................  17
    5.3.2   Path Selection for Traffic Engineering  .............  20
    5.3.3   Policy Consideration in Path Selection  .............  20
    5.3.4   Result of Path Selection  ...........................  20
    5.4     Path Control  .......................................  21
    5.4.1   MPLS Control Plane Concepts for ASTN  ...............  21
    5.4.1.1 Upstream and Downstream  ............................  21
    5.4.1.2 Generalized Label  ..................................  22
    


Y. Xu et al.                                                      Page [2]

Internet Draft          GMPLS Architecture for ASTN               March 2001


    5.4.1.3 Label Space   .......................................  23
    5.4.1.4 Label Binding  ......................................  23
    5.4.1.5 Label Distribution  .................................  24
    5.4.1.6 LSP Tunneling and Label Stack  ......................  24
    5.4.1.6 Circuit LSP Concatenation   .........................  25
    5.4.2   LSP Information Maintenance  ........................  25
    5.4.3   LSP Restoration  ....................................  25
    5.4.3.1 LSP Restoration Stages  .............................  25
    5.4.3.2 Link Level Restoration  .............................  26
    5.4.3.3 Path Level Restoration  .............................  26
    5.4.4   Circuit LSP Verification   ..........................  27
    5.4.5   Control Plane Failure Handling ......................  27
    6       Security Considerations  ............................  28
    7       Intellectual Property  ..............................  28
    8       Acknowledgment  .....................................  28
    9       Authors' Addresses  .................................  28
    10      References  .........................................  31


1. Specification

   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.



2. Acronyms
   
   ASTN :   Automatically Switched Transport Network
   OTN  :   Optical Transport Network  
   NE   :   Network Element
   ENE  :   Edge Network Element
   SNE  :   Source Network Element
   DNE  :   Destination Network Element
   SLA  :   Service Level Agreement
   BER  :   Bit Error Ratio
   LSP  :   Label Switched Path
   PDM  :   Packet Division Multiplexing
   TDM  :   Time Division Multiplexing
   SDM  :   Space Division Multiplexing
   LO   :   Low Order
   HO   :   High Order
   PS   :   Protection Switching








Y. Xu et al.                                                      Page [3]

Internet Draft          GMPLS Architecture for ASTN               March 2001


3. Introduction to Generalized MPLS Control Plane
   
   A network can be functionally divided into a data (or transport) plane, a 
   control plane, and a management plane. The control plane consists of 
   network level control components and Network Element (NE) level control 
   components. The network control plane perform network level coordination 
   functions including: topology information management (acquisition, 
   representation, dissemination), decision making (e.g., path selection), 
   and action invocation (e.g., signaling). 

   Traditional circuit switching transport networks have virtually no automatic 
   network control. This resulted in very slow service provisioning. 
   ASTNs, such as optical transport network, are required and feasible in the 
   emerging data centric networks which are growing very rapidly. In particular,  
   automatic switching of available capacity is needed to quickly and 
   efficiently provision bandwidth wherever and whenever needed to address 
   the increasing demands for network bandwidth.

   Even though differences exist in the technology and operation of 
   different transport networks, especially within the data or transport 
   planes, all switched transport networks share very similar 
   characteristics in their control planes. These control plane commonalties 
   are also shared by connection-oriented data networks, such as MPLS, as 
   noted in [MPLamdaS].

   It is now widely recognized that it is desirable to establish generalized 
   control architecture that is applicable to different technologies because 
   it facilitates network inter-working and simplify network operation. One of 
   the major applications of MPLS is the set-up of explicitly routed LSPs [MPLS-
   ARCH] for Traffic Engineering (TE) purposes. Given that a label switched path 
   (LSP) is an instance of a network connection, it is evident that the LSP 
   concept can be extended to support the operation of many type of network 
   connections via an MPLS-based control plane. The applicability to multiple 
   network domains makes MPLS a good candidate for a generalized control plane 
   protocol. For this reason, there is significant interest throughout the 
   industry to define a generalized MPLS-based traffic engineering control plane 
   for ASTN. 

   However, in order to generalize and apply the MPLS TE control plane concepts 
   to ASTN, it is important to recognize the unique features of ASTN which 
   demands specific adaptations to the MPLS control protocols. Specially, ASTN 
   has many unique features that should be taken into consideration in the 
   design of pertinent control plane architectures. Examples of these unique 
   features include:      

   -- Network level features
      -- In ASTN, control plane and transport plane are typically independent of 
         each other. While in IP network, control traffic and user traffic are  
         mixed together. 



Y. Xu et al.                                                      Page [4]

Internet Draft          GMPLS Architecture for ASTN               March 2001

 
      -- ASTN serves as the network backbone for user traffic. The traffic 
         load and topology changes are not as dynamic as those for many 
         packet switched data networks.
      -- ASTN provides services with different types of SLAs (BER, 
         availability, maximum downtime and etc.) from those that typically 
         prevail for data connections.
      -- ASTN has additional link state parameters than the link state 
         metrics used for data network topologies. 
      -- Circuit paths are setup with many technology dependent constraints. 
         The path selection process for circuit connections is also impacted 
         by technology-specific considerations.       
      -- Data LSPs are generally considered to be uni-directional while 
         circuit connections can be uni-directional or bi-directional.
      -- Data LSPs reserve logical resource, which can be sharable among LSPs. 
         While circuit LSPs allocate physical bandwidth which is non-sharable.

   -- Network element level features
      -- Circuit switched NEs may have hundreds or even thousands of 
         physical ports. Many of them terminate on the same neighbor and 
         share the same attributes.       
      -- Ports in circuit switched NE are typically unnumbered interfaces 
         without assigned IP addresses. 
      -- Each physical port may include many technology dependent 
         attributes.  
      
   ASTN also have an impact on the data network control plane. In particular, it 
   changes the data network's basic assumption that the transport network 
   consists of fixed pipes. In the new paradigm, the transport network can be  
   conceived as a large circuit switch with a dynamically configurable back 
   plane. Network devices that are connected to a ASTN can potentially establish 
   direct connectivity with each other. Effort should be expended to enable data 
   networks exploit these new capabilities of ASTN to achieve true end-to-end 
   network traffic engineering. 

   As more applications enabled by ASTN are discovered, they will affect 
   existing network characteristics and generate new requirements. This 
   demands a control plane architecture that is flexible and easily 
   extensible.














Y. Xu et al.                                                      Page [5]

Internet Draft          GMPLS Architecture for ASTN               March 2001


4. Architecture Overview
   
   A well-designed control plane architecture should provide service 
   providers with enhanced network control capabilities and relieve 
   operators from unnecessary manual operations.  At the same time, it 
   should facilitate network interoperation and integration between 
   networks with different data plane technologies. Furthermore,

   -- It should be applicable to all circuit switched networks; e.g., 
      analog signals (non O-E-O), OTN, SONET/SDH, and PDH. In order to 
      achieve this goal, it is essential to isolate technology dependent 
      aspects from technology independent aspects and to address them 
      separately.

   -- It should be sufficiently flexible to accommodate different 
      network scenarios (service provider business models). This goal 
      may be achieved by partitioning the control plane into a number of 
      distinct components. This, for example, allows vendors and service 
      providers to decide the logical placement of these components, and 
      also allows the service provider to decide the security and policy 
      aspects of these components. 
 
   Within the context of ASTN, the control plane deals primarily with connection 
   services. In a larger sense, this functionality is a subset of the network 
   management functions; the complement being  aspects of fault management, 
   configuration management, accounting management, performance management, 
   security management, and policy management functions. MPLS control plane 
   components could be applied to ASTN to achieve a distributed connection 
   control. It should also be noted that for many circuit connection services, 
   the MPLS based control plane is just one alternative, as other solutions 
   are also available to provide the same functionality in a less automated 
   fashion. 


   4.1 System Components

   Following the MPLS traffic engineering control plane model defined in 
   [MPLS-TE], the intra-domain GMPLS control plane can be divided into several 
   modules, namely, element level resource discovery, state information 
   dissemination, path selection and path control modules. These functional 
   components work together to complete each other. Their structure and the 
   relationships between them  establish  the overall architecture. This 
   approach is intended to avoid focus upon certain functional components of the 
   architecture, to the inadvertent exclusion of others, which could result in 
   unnecessary dependencies and  poor network level solutions. The basic modules 
   are described below.
  





Y. Xu et al.                                                      Page [6]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   -- Network Element Level Resource Discovery
      Resource discovery is defined as the transaction that establishes, 
      verifies, updates and maintains the NE adjacencies and their port-
      pair association for their transport (data) plane. 

      The resource discovery module generates a complete NE level resource 
      map, which include attributes, neighbor identifiers, and pertinent 
      real-time operational status. The control procedure of this component 
      should be very generic. At the same time, some of its sub-components  
      may have to be technology and perhaps even product specific. 

      Beyond physical resource discovery, this component may also 
      involve service/policy negotiation between adjacent NEs. 

   -- State Information Dissemination
      State information dissemination distribute topology information throughout 
      the network to form a consistent network level resource view among NEs. It 
      involves a number of steps. First, the NE level physical resource map is 
      acquired and summarized into logical links (section 5.2.1) based on link 
      attributes. These logical link level information are then distributed 
      throughout the network by either piggybacking onto the control network 
      IGP, or through some other means such as application layer protocols.  

      Key issues that relate to this module include the specific types of state 
      information that needs to be distributed and the mechanisms for 
      representing and disseminating this information. 

   -- Path Selection
      Transport network routing procedures typically utilize explicit 
      routing, where path (connection) selection can be done either by 
      an operator, through the use of simulation and planning tools, by 
      an NMS or by the network itself. 

      In ASTN, a path (connection) is normally requested with certain 
      constraints. This requires constrained-based routing that

      -- Conform to constraints such as physical diversity, etc.
      -- Achieve traffic engineering objectives in the transport network
      -- Adhere to operator policies on routing such as preferred routes
      -- Conform to network specific constraints

   -- Path (Connection) Control
      Path control deals with path operations such as path creation, 
      deletion and modification (auto-rerouting and protection 
      switching). This is an area that many MPLS control plane protocols 
      are applicable.
 
   Details of these functional components are elaborated in Section 5.




Y. Xu et al.                                                      Page [7]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   4.2 Network Overview

   A typical connection operation within a single autonomous system (AS) 
   involves the following types of roles played by various entities: 
   service agent, edge NE (ENE), and intermediate NE (INE). 

   -- The service agent represents the system that originates an end-to-
      end circuit connection request. This role could be played by a client 
      NE, NMS, or network scheduling tool. It may or may not be within the 
      scope of ASTN control plane.
      
      Depending on which network application scenario is supported, and 
      which services are provided by the service provider, the request from 
      the service agent to the source NE may contain the whole explicit 
      path (connection), or a subset of the explicit route, or only indicate 
      path (connection) end points. The service agent may also include  
      constraints, objective criteria, and policies as part of the request. 

   -- ENE has two functional roles: source NE (SNE) role and destination NE 
      (DNE) role. SNE initiates the connection set-up operation through the 
      associated transport network upon receipt of an authenticated 
      request from the service agent. DNE is the termination point of 
      the connection set-up operation  over the transport network.  
      SNE and ENE are irrelevant to transport traffic flow direction. That 
      is, they do not imply the direction of user traffic flow. Furthermore, a 
      particular node may perform the role of SNE for one connection set-up 
      operation, and perform the role of DNE for another connection set-up 
      operation.

      A SNE typically supports all the functional components mentioned 
      above.  In addition to having the capability to play the role of INE 
      (see below) and DNE, a SNE  may also support the capability to perform 
      path selection computations. Furthermore, an SNE should maintain an 
      inventory of path information for all circuit LSPs that were 
      originated from itself. 

   -- Intermediate NE (INE) exists along the path between an SNE and a DNE. 
      An INE accepts signaling requests from adjacent NEs and executes them 
      by rearranging its switch matrix and performing other local operations 
      to facilitate establishment of the connection. In executing connection 
      setup requests,  an INE selects specific physical interface according 
      to its local knowledge and according to pre-defined policies. 

      INE maintains LSP ID as a reference to support other types of 
      requests. It doesn't need to maintain full path (connection) level 
      information. However, it does need to maintain local physical 
      resource information for all LSPs that pass through it. Such local 
      information need not exist on other NEs, except in the form of 




Y. Xu et al.                                                      Page [8]

Internet Draft          GMPLS Architecture for ASTN               March 2001
 

      resource availability and usage information which the INE may 
      disseminate to other nodes.
      
   The roles of ENE and INE are associated with each LSP through the 
   switched transport network. However, each NE in the network could 
   play any or all of these roles.  Specifically, the role an NE plays 
   depends upon context, especially its role in the establishment of each  
   LSP traversing it. 

   An LSP traversing multiple Autonomous Systems (AS) may be divided into 
   multiple AS-sections, such that each AS-section corresponds to one AS. 
   Each section may be considered to have its own AS ENE and AS INE. 
   Corresponding interfaces and responsibilities within the context of 
   multiple ASes require further study.
 

   4.3 Control Plane Network and Requirements

   The underlying control plane infrastructure consists of a set of 
   distributed controllers that communicate and coordinate with each other 
   to facilitate connection set-up. A data communication network is needed 
   to enable control messages to be exchanged between controllers via the  
   distributed control plane. There is no separate control plane network for the 
   in conventional IP networks, where control messages are mixed with user data 
   traffic. For circuit based networks, an independent control plane network is 
   a fundamental requirement because a typical transport NE doesn't have the 
   capability to process the data traffic through its user traffic channels.

   A control plane network in ASTN can be either in-band or out-of-band relative 
   to the user traffic channels. Thus, a generic control plane architecture must 
   not make assumptions about its physical transport medium for control traffic. 
   An implication of this is that the control plane network of an ASTN may have 
   a different physical topology from its transport plane network.

   Another implication is that the health of the control plane and transport 
   plane should be individually maintained. This requires separate notifications 
   and status codes for the control plane and transport plane. In the event of 
   control plane failure (for example, communications channel or control entity 
   failure), new circuit LSP (connection) operations may not be accepted, but 
   existing connections shall not be dropped. 

   Inter-working of the control networks is the first step towards control plane 
   inter-operation.  To maintain a certain level of  interoperability, it is 
   desirable to have an IP based control network. Control networks from 
   different administrative domains or different types of transport networks can 
   be interconnected in various ways to facilitate control interaction  between 
   different domains, or types of networks.





Y. Xu et al.                                                      Page [9]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   The control network is an integral but independent part of the overall 
   control plane. Transport network operation heavily depends on its underlying 
   control plane network. Thus, control network has many strict requirements, 
   some of which are listed below:
 
   -- Control plane network must be secure. This requirement stems from both 
      signaling and routing perspective. The fact that the routing information 
      exchanged over the control plane is service-provider specific and security 
      is critical. Service providers may not want to expose internal network 
      information outside their network boundaries even to their own customers. 
      Meanwhile, control plane network must prevent spoofing and hacking of 
      connection services. 
   
   -- Control network's reliability has to be guaranteed in almost all 
      situations, even during what might be considered catastrophic failure 
      scenarios of the service transport networks. Failures in the user-traffic 
      transport network that also affect the control plane may result in the 
      inability to restore traffic or a degradation in the service restoration 
      time. 

   -- The user traffic connection service performance largely depends 
      on its control message transportation. Time sensitive operations, such as 
      protection switching, may need certain QoS guarantees. Furthermore, 
      message transportation should be guaranteed or recovered quickly in  event 
      of control network failure.

   -- The control network needs to be extensible and scalable in order to 
      make the control plane scalable as the requirements imposed upon it
      increases. 























Y. Xu et al.                                                      Page [10]

Internet Draft          GMPLS Architecture for ASTN               March 2001


5. Detailed Architectural Considerations

   5.1 Network Element Level Resource Discovery

   5.1.1 Element Level Resource Table

   For circuit switched NEs, physical resources are usually dictated by 
   interface ports and their characteristics. Each NE maintains its own 
   resource table indexed by local port ID. The content of the NE level 
   resource table is as below. Physical and logical attributes may span 
   multiple columns. 
   

+------------+-------------+------------+----------+---------+---------+                           
| Local Port |  Neighbor   |  Neighbor  | Physical | Logical |  Oper.  |
|     ID     |  NE addr.   |  Port ID   |   attrs  |  attrs  |  State  |   
+------------+-------------+------------+----------+---------+---------+
                      
                   Figure 1: NE Level Resource Table
 
   Physical attributes are technology and vendor specific. Examples are:
   -- Signal Type (Encoding, Multiplexing Structure, Wavelength Grid and etc.)
   -- Optics Type (SR, LR, etc.)
   -- Directionality (Transmit, Receive, Bi-directional)
   -- Payload Type

   Several physical attributes can be abstracted into one logical attribute. 
   Meanwhile, logical attributes may not be assigned to a particular physical 
   port directly, instead, they may describe characteristics of a physical port 
   pool. Logical attribute examples are:
   -- VPN ID
   -- SRLG (Shared risk link group)[OPT-BUND]
   -- Service type 

   Operational state indicates the real-time state of a physical port. 
   It includes:
   -- Unequipped
   -- In-service
   -- Standby
   -- Failed
   -- Mis-configured
   -- Unknown

   
   5.1.2 Resource Discovery Stages
   
   Resource discovery can be achieved through either manual provisioning 
   or automated procedures. These procedures are generic while the specific 
   mechanisms and control information can be technology dependent. 
   
   

Y. Xu et al.                                                      Page [11]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   Typically, there are several steps involved in resource discovery:

   -- Self resource awareness/discovery
      The results of self resource awareness/discovery is to populate the 
      local ID, physical attributes, logical constraints parameters in the 
      element resource table. 

   -- Neighbor discovery and port association
      This step discovers the adjacencies in the transport plane and 
      their port association and  populates the neighbor NE address and port 
      ID fields in the resource table.

      Because the control plane network may be different from the 
      transport plane network in ASTN, NEs that are not adjacent in the 
      control plane network may be adjacent in the transport network. In 
      order to unambiguously identify the transport plane neighbors and 
      their port associations, it is essential to have in-band events (along 
      the transport plane) coordinated  with other control messages (along 
      the control plane). 

      An example of in-band events for NE capable of electrical signal 
      processing in the transport plane is a byte stream containing the 
      local NE address and port ID. Both [LMP] and [ND-SONET/SDH] adopt this 
      approach.  Bi-directional links may use in-band signaling between 
      both ends. Uni-directional links may employ messages through the 
      control network to coordinate with in-band signals to achieve 
      bi-directional control coordination. [AND] 

      For a pure OXC without O-E-O capability, an analog signal (power 
      on/off) could principally be used as the in-band event. Control 
      messages over the control network  can then be used to co-ordinate  
      and associate additional significance with the in-band event to 
      identify neighbor adjacency and port associations. Details of this  
      type of scenario are for further study.  
 
   -- Resource verification and monitoring
      After neighbor resource discovery, neighbors should detect their 
      operation state and verify their configurations such as physical 
      attributes in order to  ensure  compatibility. Such verification can 
      be done through control message over the control plane network without 
      using in-band signals. In case of any mismatch, the port should be 
      marked as mis-configured, and notification should be issued to 
      operators.

      Resource monitoring is a continual process. Neighbor discovery and 
      port association procedures are repeated periodically. Resource 
      monitoring procedures update resource state and report changes to 
      relevant control entities. 
    



Y. Xu et al.                                                      Page [12]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   -- Service negotiation
      Service negotiation essentially covers all aspects related to service 
      related to rules/policy negotiation between neighbors. 

      A typical example is the negotiation of rules for label binding and 
      assignment. In this case, neighbors build up a label binding and 
      look-up table according to the physical connectivity map. They may 
      exchange information on technology specific details such as 
      multiplexing structure. They may also negotiate the semantics for complex 
      labels, and decide upon label assignment order. 

   
   5.2 State Information Dissemination
 
   In link-state routing, ASTN links can be represented either as point-to-
   point or non-broadcast multiple access links.  
   

   5.2.1 Logical Link/Bundle

   Typically, core circuit switches contain thousands of physical ports. 
   Therefore, scalability requires minimizing global information and keeping 
   information and decision making locally as much as possible. For this 
   reason, link aggregation plays a key role in ASTN topology  representation. 
   Parallel link connections can be summarized into an aggregate logical link, 
   which hides the link connection details not necessary for network level 
   control functions, such as path selection.  The summarized information is 
   then distributed to the rest of the network.

   A logical link or bundle is defined as a collection of link connections 
   that share some common logical or physical attributes that are 
   significant for path selection purposes. Link connections within a bundle 
   are equivalent for routing purposes. However, the notion of equivalence 
   is not static. It is configurable according to the service providers' 
   requirements. The granularity of bundling abstraction can range from 
   physical tributary to node and even to AS. 

   The granularity of bundling can also be used to balance between network 
   operational performance optimality and control plane scalability. The 
   more details that are depicted in the topology database, the more 
   accurate the path selection could be. However, too much information could 
   result in an implementation that is not scalable. The trade off needs to 
   be carefully considered and engineered. 

   Bundling details are technology specific. Below are some examples of 
   bundling for different technologies:

   -- SONET/SDH
      4 OC48s with the same multiplexing structure to the same neighbor.



Y. Xu et al.                                                      Page [13]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   -- Wavelength
      100 protected wavelengths with wavelength convertibility to the same 
      neighbor 

   
   5.2.2 Link State Information 

   Link state information includes both static information and dynamic 
   information. This information may be technology dependent.

   -- Static information is usually required for circuit operation. It 
      includes neighbor connectivity, logical link attributes (which 
      could be the same as individual attributes), total bandwidth and 
      etc.

   -- Some dynamic information are required for circuit LSP operation, 
      while others are mainly used for traffic engineering purposes. 
      Dynamic information includes information that changes constantly,  
      such as bandwidth availability, current bandwidth fragmentation 
      information, etc.
   
   The total number of attributes in an ASTN can be huge. The decision as to  
   what should be distributed and what could be negotiated during connection 
   setup requires a compromise  between control plane scalability 
   and connection operation performance. The more the number of attributes 
   that are conveyed in link state information, the more accurate the path 
   selection decisions. However, it may result in reduced control plane 
   scalability. In general, scalability and simplicity should be favored 
   above abundance of information and call setup speed in case of 
   irreconcilable conflicts. Stability is another crucial consideration. The 
   more the amount of information conveyed and the more frequent their rate 
   of change, the more the network will tend towards less stable operating 
   regimes.
 
   The objective should be to distribute just enough link state information 
   to support connection set-up operations. More information could be 
   distributed  provided it does not affect control plane scalability and 
   stability.  

   Furthermore, information reduction mechanisms should be utilized whenever 
   possible. The basic concept is to only flood what is needed to accomplish 
   specific control goals. For example, static information and dynamic 
   information could be flooded independently. When building up an initial 
   network topology database, all pertinent static and dynamic information needs 
   to be disseminated. Subsequently, as long as static information remain 
   unchanged, only the dynamically changing information needs to be flooded 
   through the network. 





Y. Xu et al.                                                      Page [14]

Internet Draft          GMPLS Architecture for ASTN               March 2001
  

   5.2.3 Link State Dissemination Mechanisms

   Link state information can be piggybacked through IGP or EGP of the 
   control plane network according to network application scenarios. For 
   example, mechanisms introduced by [OSFP-OMPLS]/[ISIS-OMPLS] can be used 
   to disseminate ASTN link state information within a single area. 
   
   Alternately, optical link-state and general ASTN advertisement can be 
   built as a separate application on top of any control network. This 
   solution can tailor existing IGP's behaviors to ASTN and meanwhile 
   permits flexibility in choice of the underlying control plane transport 
   network.


   5.2.4 Flooding Control

   Topology updates should happen only when a significant topology 
   change  occurs or upon expiration of a periodic timer. 

   -- Static information change requires immediate link state 
      information flooding. 
   -- Flooding of dynamic information change is triggered by thresholds 
      as defined below. 
   -- Periodic topology refreshing is needed to ensure that network 
      topology information in all NEs is consistent and correct.
   
   Some dynamic attributes are important for connection operation. For 
   example, to SONET/SDH network, bandwidth continuity is critical for 
   connection operation. Because of frequent connection operations, a 
   SONET/SDH connection may become fragmented. An OC48 pipe with total 
   24 free STS-1s left doesn't mean that it can accommodate an OC-12c 
   connection request. So bandwidth continuity change should also be 
   distributed in order to avoid rejection of connection requests.

   Other dynamic attributes are important for traffic engineering in ASTN. 
   For example, the bandwidth consumption state of a logical link may  
   be used to adjust link cost and balance network traffic.

   The frequent change of link states requires frequent flooding in 
   order to keep the topology database updated. However, there is a 
   tradeoff between accuracy of the topology and the scalability of the 
   control plane as note earlier. Operators can control link state flooding 
   by configuring thresholds and frequencies according to a particular 
   network situation. Generally, there are two types of thresholds: absolute 
   threshold and relative threshold. 

   -- Absolute threshold defines change relative to total resource. 
   -- Relative threshold describes changes relative to previous 
      available resource. 
   


Y. Xu et al.                                                      Page [15]

Internet Draft          GMPLS Architecture for ASTN               March 2001
 

   Relative thresholding is preferable to absolute thresholding. Using 
   bandwidth availability as an example, it is desirable in general to 
   advertise less frequently when a link is lightly loaded and increase 
   the frequency as the link loading increases. This is automatically 
   accomplished by defining a threshold for the relative change in 
   available bandwidth. 

   There could be thresholds for key attributes of a logical link. A 
   significant change of any relative attribute could trigger flooding. 
   Details of how to set thresholds to control flooding are outside 
   the scope of this document.
   

   5.3 Path Selection

   Path selection could be done either off-line or on-line. The path 
   selection algorithms may also be executed in real-time or non-real time 
   depending upon their computational complexity, implementation, and  
   specific network context. Also, off-line computation is typically a 
   centralized operation whereas on-line computation is  typically distributed.

   -- Off-line computation may be facilitated by simulation and/or network 
      planning tools. Off-line computation can help provide guidance to 
      subsequent real-time computations.

   -- On-line computation may be done whenever a connection request is 

      received. 
   
   Off-line and on-line path selection may be used together to make 
   network operation more efficient. Operators could use on-line 
   computation to handle  a subset of path selection decisions and use off-
   line computation for complicated traffic engineering and policy related 
   issues such as demand planning, service scheduling, cost modeling and 
   global optimization. 

   In case of on-line computation, there are two choices: explicit 
   routing or hop-by-hop path selection. 

   -- In ASTN, explicit routing is preferred as it provides superior 
      traffic engineering capabilities. Explicit routing may in fact be 
      mandatory if multiple constraints are considered in the path selection 
      decision. 

   -- Hop by hop routing can make more accurate next hop choice because 
      each node can consult its local resource information that may be 
      unavailable to other nodes. However, hop-by-hop routing requires 
      path calculation at each node and needs loop-prevention mechanisms. 
      Hop-by-hop routing is also more difficult when constraints other than 
      additive link metrics are taken into account.



Y. Xu et al.                                                      Page [16]

Internet Draft          GMPLS Architecture for ASTN               March 2001
    

   5.3.1 Routing Constraints in ASTN 

   There are potentially many routing constraints of interest in ASTN. Some 
   of them are technology specific, such as optical constrains addressed by 
   [OLCP]. In the following, we highlight some of the major constraints of 
   interest, but the list is not meant to be exhaustive. Also, the 
   discussion is in general equally applicable to all types of circuit 
   networks. However, we highlight any differences where applicable.

   One of the major services provided by a transport network is restoration. 
   Restoration introduces several routing constraints. A major one is that of 
   physically diverse routing. Restoration is often provided by either pre-
   computing or finding  alternate routes for connections in real-time. These 
   alternate routes need to be physically diverse from the primary route in at 
   least the failed link  for efficiency purposes  or completely diverse. The 
   simplest form of diversity is node disjointness of the primary and alternate 
   routes. More complete notions of diversity can be addressed by logical 
   attributes such as shared risk link groups (SRLG). These logical attributes 
   are abstracted by operators from several physical attributes such as fiber 
   trench ID and destructive areas. Because methods of automatically identifying 
   physical separation do not exist yet these physical attributes require 
   operators' configuration. 

   In order to address this constraint, path selection algorithms are 
   needed that can find a diverse pair of routes in the specified fiber 
   graph. Algorithms for node-disjoint diverse routes have been 
   developed [DISJ-PATH]. 

   Another restoration constraint is related to shared capacity mesh 
   restoration architectures [ON-REST]. In these architectures, 
   restoration capacity is shared among multiple demands. In order to 
   guarantee that restoration capacity is available on a chosen route, 
   one needs information on the free capacity on that route, demands 
   whose alternate routes share that route or some links on it and their 
   failure sets. Consider two demands that do not share any link on 
   their primary routes but share parts of an alternate route. In this 
   case, the capacity on the alternate route can be shared between the 
   two demands since the primary routes (and hence demands) can hardly 
   at the same time under single-failure scenarios. Optimal routing in 
   these cases requires considerable network level information and good 
   heuristics that limited information about the network and routing of 
   demands. Some heuristic approaches are proposed in [ON-REST]. 

   However, further study is needed to develop a complete solution.

   Other constraints of interest include node/LSP inclusion/exclusion, 
   propagation delay, wavelength convertibility and connection bandwidth 
   among others. Node exclusion involves specifying a set of nodes that 
   should be avoided for routing. These are typically specified on a 
   connection basis. An interesting application of node exclusion has 
 


Y. Xu et al.                                                      Page [17]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   been proposed by Japan Telecom [DIST_AREA]. Certain office sites of 
   this carrier are in earthquake prone areas and to the extent possible 
   it is desired to route traffic of premium customers so as to avoid 
   these sites. A possible application of node inclusion is to route 
   traffic through a site that has some special equipment such as for 
   connection monitoring. Since transport connections are physical 
   connections involving fixed time slots or wavelengths, there are no 
   queuing delays like in packet networks. However, propagation delay 
   may be a factor for large global networks and especially networks 
   with satellite links. Consider traffic from New York to London on a 
   global network. It may be undesirable to route this traffic the long 
   way around the world (over the Pacific Ocean) and rather choose the 
   short route over the Atlantic Ocean. This can be realized by 
   requiring the propagation delay of the chosen route to be less than a 
   certain value.

   Wavelength convertibility is a problem encountered in 
   wavelength/waveband networks. It refers to the ability to cross-
   connect two different wavelengths. The wavelengths may be completely 
   disparate or just slightly different due to differences in the ITU 
   grid wavelengths supported by a network vendor. Wavelength 
   convertibility is typically accomplished via use of electrical 
   transponders. Owing to the cost of OEO conversions, operators may 
   choose to selectively deploy transponders. In this case, end to end 
   connections have to employ the same wavelength through the network. 
   This constraint introduces considerable challenges in path selection. 
   In order to determine if a connection can be supported on a given 
   route, path selection needs to determine if the same wavelength, say 
   red, is available on each leg of the route. This requires that the 
   path selection be aware of all the available wavelengths on each leg 
   of the route. This information may be unavailable if link bundling 
   includes all wavelengths on a link into the same bundle. When routing 
   is carried out in a distributed manner at source NE of the connection, 
   this implies that considerable local information about the status of 
   network links needs to be distributed across the network. An alternate 
   less efficient approach might be to guess availability of wavelengths on 
   a computed route and determine feasibility of the route via local probing 
   of link resources along the computed route. However, this approach is 
   likely to result in considerable connection crank-backs and wasted 
   network processing resources. When wavelength convertibility is available 
   at each intermediate NE, however, no information about availability of 
   particular wavelengths on a link is needed. In this case, the total 
   number of available wavelengths is sufficient for routing purposes. 
   The above discussion applies equally to TDM circuit networks by 
   considering time slots rather than particular color wavelengths. Time 
   slot interchange capabilities are analogous to wavelength 
   convertibility.





Y. Xu et al.                                                       Page [18]

Internet Draft          GMPLS Architecture for ASTN                March 2001


   Bandwidth availability is an important consideration in routing. This 
   is simplified in a wavelength optical network since all requests are 
   for end to end wavelength paths. However, in a TDM transport network 
   such as SONET/SDH, connection requests can be variable bandwidth 
   ranging from VT1.5 to as high as OC-768 with current technologies. 
   Routing needs to ensure that sufficient network capacity is available 
   on the chosen route to support the connection. Further challenges are 
   introduced by different concatenation schemes in SONET/SDH networks. 
   An example would be a contiguous concatenated STS-3c signal, which 
   require three adjacent time slots be allocated. This implies that a 
   time slot map of the link be distributed to all nodes in the network 
   to facilitate routing decisions. Alternately, in the logical link 
   representation, one would need N different logical links to represent 
   all possible STS-N signals. This could be expensive in terms of 
   control network bandwidth. A preferable approach is to advertise 
   just the largest contiguous block of time slots available on a 
   logical link instead of the entire time slot map. This is sufficient 
   to determine supportability of a connection on a link. Note that the 
   detailed information on local resource availability is only used for 
   routing decisions. Actual assignment of local resources to a 
   connection is performed by individual NEs.


   5.3.2 Path Selection for Traffic Engineering
   TBD


   5.3.3 Policy Consideration in Path Selection

   Operators' policy aspects of routing should also be considered. While 
   distributed, dynamic path selection has significant advantages such 
   as scalability, it is often advantageous to provide the network 
   operator some degree of control over path selection. Such control can 
   be provided in multiple ways. One possibility is to allow the 
   operator to provide a set of preferred routes between a source 
   destination pair. Automatic path selection may then choose between 
   these preferred routes. Alternately, static link weights could be 
   employed. The automatic path selection may then choose routes, when 
   feasible, that minimizes the static link weight. But the preferred 
   routes should typically be used only as a guide as in the extreme 
   case they reduce to fixed pre-determined routes and one loses the 
   flexibility to correct any mismatch between network capacity and 
   traffic patterns. 
   

  






Y. Xu et al.                                                      Page [19]

Internet Draft          GMPLS Architecture for ASTN               March 2001


 5.3.4. Result of Path Selection

   The result of explicit path selection is a linked list of explicit 
   routed hops. In order to provide just enough information for each NE 
   to choose the right physical resource for circuit connection operation, it 
   should be in logical link level of details.  

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      ER-Hop           (Mandatory)             |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                    Logical Link ID    (Optional)              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                     Figure 2: Path Selection Result


   Explicit hop can be either node ID, AS ID or existing LSP ID as 
   defined in current MPLS signaling protocols. 

   The logical link (bundle) is defined in 5.2.1. It's flexible in 
   usage. For example, a logical link ID can be a VPN ID. If a low order 
   SONET LSP needs to tunnel through a existing high order SONET VPN, it 
   can use this VPN ID to restrict which resource to use. This concept 
   is similar to LSP tunnel, except, instead within a LSP, it's within a 
   pre-established circuit VPN.



   5.4 Path Control   

   5.4.1 MPLS Control Plane Concepts for ASTN

   In data networks, MPLS covers both the control plane (label binding, 
   label distribution and etc.) and the transport plane (packet 
   forwarding). Label binding associates FECs to labels; label 
   distribution distributes label-binding information. Together with 
   mapping between FEC and next hop, the label switching forwarding 
   table is constructed to forward packets. 

   In circuit switched networks, there is no packet forwarding. Labels 
   are only used to set up LSPs by making cross connects link by link. After 
   LSPs are set up, there is no dynamic label swapping at all. So only the 
   MPLS control plane components are truly applicable to circuit switched 
   networks. 

   There are several ways to apply MPLS control plane concepts in 
   circuit switched networks. Given that circuit paths are service-
  


Y. Xu et al.                                                      Page [20]

Internet Draft          GMPLS Architecture for ASTN               March 2001

 
   driven, one possible understanding is to treat the service request as 
   an FEC. It contains next hop (or destination address for hop by hop 
   routing) and incoming external interface (e.g., if negotiation is not 
   required at connection creation time) or path constraints ( e.g., if  
   negotiation is required). Because labels are used for traffic 
   forwarding, they are analogous to cross connect IDs. Label binding is 
   then conceptually equivalent to choosing cross-connection across the 
   switch matrix. 

   An alternate interpretation can be constructed as follows: In circuit 
   switched networks, setting up a LSP means making cross connects along 
   the desirable path. Labels are used to determine cross connect 
   configurations. Assuming a non-blocking switch fabric, determining a 
   cross-connect means determining external ingress and egress physical 
   interfaces. So labels are used to indicate specific external interfaces. 
   Label binding entails choosing the correct ingress or egress interface 
   according to path selection decision and local policies. 

   In both of the above interpretations, making cross connects is equivalent 
   to writing to a label switching forwarding table. After the path is set 
   up, user traffic simply follows the dedicated physical path (cross 
   connects). The concepts below elaborate on the second interpretation. 


   5.4.1.1. Upstream and Downstream 

   Upstream and downstream in circuit switched network are based on path 
   create request direction. They are irrelevant to user traffic 
   direction. The NE that receives the request first is treated as an 
   upstream NE relative to the NE that receives the request later. 


   5.4.1.2. Generalized Label 
   
   What is Label? Label is associated with a specific switchable data 
   flow. This generic definition can be applied to different technologies.       

   A cross-connect in a circuit switched NE is an internal connection between 
   two specific external interfaces. So to ASTN, a label is used to identify a 
   specific external interface, for example, a OO wavelength, an STS-48c port
   or an STS-3c within a OC48 port.

   Different from packet switched network, in ASTN, a label is bound with a 
   specific "physical" interface. There are two types of label formats for 
   ASTN. 
       <1> Basic format and 
       <2> hierarchical format. 


    


Y. Xu et al.                                                      Page [21]

Internet Draft          GMPLS Architecture for ASTN               March 2001


5.4.1.2.1 Basic Label Format
    
   In order to define a label's format, we should understand how 
   external interfaces are normally represented in circuit switches. 
   Typically, a specific external interface can be identified as a 
   concatenation of a physical port ID and channel ID within the port 
   (assuming non-blocking switch fabric).

    -- Port identifiers are product dependent. Different vendors have 
       different naming and addressing structures for their products. 
       For example, a port ID may be prefixed with bay ID, shelf ID and 
       slot ID. 

       However, neighbors don't need to understand the semantic of each 
       other's port ID. The port association information in the NE resource 
       table can serve as a look-up table. In the example below, when A 
       asks B for a connection, A will find B's port ID through its 
       resource table and use it when communicating with B.



                        +-----+                  +-----+
                  ------|\    |                  |    /|--------
                        | \   |                  |   / |
                        |  \  |                  |  /  |
                        |   \ | x               y| /   |
                        |    \|------------------|/    |
                        |     |                  |     |
                        |     |                  |     |
                        |     |                  |     |
                        |  A  |                  |  B  |
                        +-----+                  +-----+
                                 
                         Figure 3: Label Illustration 



   -- Channel ID is technology dependent. Generally, there are different 
      multiplexing structures for different technologies. Channel ID 
      indicates the channel within a port. For example, within an OC-48 
      port with STS-1 granularity, each STS-1 may have a channel ID. For 
      two physical ports connected by a physical link, these two ports 
      should share common physical attributes including multiplexing 
      structure, which are technology specific and clearly defined by 
      standards.








Y. Xu et al.                                                      Page [22]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   So the basic label format is: 

       0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                  G-Label     (Port ID)                        | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | D |              G-Label     (Channel ID)                     | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 4: G-Label Basic Format 


5.4.1.2.2 Hierarchical Format

   New LSPs can tunnel through existing LSPs of higher granularity. 
   After a circuit LSP is created, it can be treated as a FA in the 
   topology database. A new circuit LSP can tunnel through it by either 
   indicating the Connection ID in its ER hop list or within the label. The 
   high granularity LSPs work as ATM VP switching. Label is the concatenation 
   of high granularity LSP Connection/Tunnel ID and Channel ID within it.

   Hierarchical format is a more generic form for label. An Connection ID 
   is a unique identifier of a pre-established connection service. A 
   Connection ID is normally used at the sub-network boundary or client/server 
   interface and remains constant in the connection service life. Inside of 
   the sub-network, there may be several LSP IDs (used within a sub-network 
   for connection management) associated with this Connection/Tunnel ID 
   according to the connection type. For example, a 1+1 protected connection 
   has two LSP IDs associated with its Connection ID. For another example, an 
   STS-xV connection may have x LSP IDs associated with its Connection ID. 

   A hierarchical label format is:

     0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    //                 G-Label     (Connection ID)                  // 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    | D |              G-Label     (Channel ID)                     | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
                  Figure 5: G-Label Hierarchical Format 

5.4.1.3. Label Space

   For out-of-band control signaling, only "per-platform label space" is 
   applicable to circuit switches. In this case, both port ID and 
   channel/sub-channel ID sections are required. In case of in-band 



Y. Xu et al.                                                      Page [23]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   control signaling, the port section is not necessary, labels may have 
   "per-interface label space".
 

   5.4.1.4. Label Binding

   Label binding include both FEC to label binding and label to next hop 
   binding. Label to next hop binding in ASTN is hard-wired. FEC to 
   label binding in ASTN is selecting a specific physical interface 
   according to path selection result and local rules. It is a service-
   driven and happens at the same time when label distribution happens.

   The procedure for choosing a specific physical interface requires local 
   intelligence. A path create request message only contains logical link 
   level information. When a node receives the request, it typically has 
   many physical interfaces to choose. In order to smooth path creation
   operation, there could be local rules for choosing a specific interface. 
   For example, in bi-directional path creation request, in order to minimize 
   the chance of neighbors choosing the same interface, adjacent nodes may 
   form a master-slave relationship and decide different orders of selecting 
   interfaces. 


   5.4.1.5. Label Distribution 

   Label distribution within circuit switched network is equivalent to 
   signaling mechanism for circuit path operations. It's always ordered 
   and on-demand. MPLS signaling mechanisms can be extended as signaling 
   protocol in circuit switched networks.

   Intra-domain path operations consist of a set of basic transactions 
   between adjacent NEs. Each transaction may involve multiple signaling 
   messages.  The basic transactions are:

   -- Create:  This transaction creates a link of an end-to-end path.
      Although there is only one create transaction for the end-to-end 
      path, the resource allocation is made on a link-by-link basis. 

      MPLS signaling protocols always involve label request and 
      response. They can be mapped into path create request and response 
      directly. In general, most of circuit path constraints should be 
      considered at path selection time rather than negotiated at path 
      creation time. However, some constrains, such as wavelength preference
      could be considered at the path creation time by using label request and 
      response messages. These constrains are normally expensive to be 
      considered at path selection stage because that either control plane 
      scalability may be hurt or path selection algorithms could become too 
      complicated. 




Y. Xu et al.                                                      Page [24]

Internet Draft          GMPLS Architecture for ASTN               March 2001


      In the explicit routing case, a create request should contain 
      information that is essential for path creation, e.g., ER hop 
      list, current ER hop pointer. If the incoming label can be 
      decided, it should be given at the request time so that NEs can 
      minimize operation delay by allowing circuit switches to perform 
      cross connect and wait for response from other NEs in parallel. In 
      the example of figure 3, NE A could issue the cross connect 
      request to the local system controller and send label the request 
      downstream to B simultaneously. 

      Create response return LSP ID and connection status.

   -- Delete:  This transaction de-allocates a specific link of a LSP 
      identified by its LSP ID. 

      This request contains the LSP ID to be torn down. After a NE 
      receives this request, it releases local cross connect according 
      to the LSP ID and meanwhile forwards the request downstream. Release 
      and withdraw messages in MPLS signaling can be mapped to delete 
      request and delete response.

   -- Query:  This transaction queries the status of a specific link of 
      an existing LSP identified by a LSP ID. Current MPLS signaling 
      needs to be extended to support this function.


   -- Modify: TBD


   5.4.1.6  LSP Tunneling and Label Stack
   
   The hierarchical label defined above forms a stack for arbitrary layer of LSP 
   tunneling, with the Basic Label Format at the bottom of label stack.


   5.4.1.7 Circuit LSP Concatenation

   A new LSP can also be concatenated through several existing LSPs of 
   the same type. These LSPs must share the same characteristics. Their 
   LSP IDs may be included in path create request ER hop list.


   5.4.2 LSP Information Maintenance

   LSPs can be uniquely identified by LSP IDs. In circuit switched 
   networks, A LSP ID can be defined as a source NE address + a source 
   NE ingress label. 

   An LSP has two sets of information: ER hop list and local resource 
 


Y. Xu et al.                                                      Page [25]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   usage information. ER hop list should be maintained at the ENE. Both ENEs 
   and INEs should maintain the LSP ID and associated local physical 
   resource usage information.


   5.4.3 Circuit LSP Protection Switching (PS)/Restoration

   5.4.3.1 Stages

   Circuit LSP PS/Restoration is very important for transport network and 
   quite different from packet LSP in terms of both requirements and 
   mechanisms. Circuit LSP PS/Restoration typically includes following four 
   stages. 

   -- Failure Detection
   -- Failure Notification
   -- Traffic Restoration 
   -- Post-PS/Restoration Operation 

   Mechanisms of these four stages are technology dependent. Some 
   technologies provide special infrastructure to speed up PS. For example, 
   SONET/SDH detects LOS and LOF very quickly and uses in-band overhead bytes 
   for failure notification and co-ordinate actions. They also adopt special 
   topology (ring) and algorithms (BLSR, UPSR and etc.) for PS. 

   In order to speed up overall PS/Restoration time, each stage has to be 
   designed carefully and utilize existing infrastructure as effectively 
   as possible. For example, failure notification should avoid message-
   based indication if byte/bit stream based indication is available. In 
   case of message based notification, direct notification to end points 
   is more desirable than hop-by-hop processing. For traffic restoration, 
   handshaking and negotiation should be avoided as much as possible. 

   Circuit LSPs can be either link protected or path protected.


   5.4.3.2 Link level protection.
   
   In link level protection, PS/Restoration happens around the point of 
   failure, e.g., either the failed NE or link. In SONET/SDH, BLSR/SPRing is 
   a typical link level protection. This type of PS/Restoration requires 
   accurate fault localization, i.e., pinpointing the precise location of 
   the fault along the LSP so that rerouting can be performed around it. In 
   optical networks, fault localization typically involves OEO conversion at 
   every network element so that digital monitoring of the optical channel 
   (OCh) overhead can be carried out.  However, installing such digital 
   monitoring equipment to determine performance degradation might be very 
   expensive. Alternatively, controlling the expense by sharing the 
   monitoring equipment over many optical channels leads to an unacceptably 
 


Y. Xu et al.                                                      Page [26]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   long detection time for degraded signal condition (fault) owing to 
   correlation that have to be performed across multiple monitoring nodes.

 
   5.4.3.3 Path level protection 
   
   Path level protection is a more popular choice for mesh network. In 
   this case path restoration is done from the endpoints. Failure 
   notification need to be propagated to end points where the restoration is 
   triggered. 
 
   There are several types of path protections.

   -- Dedicated protection
      This type of protection is the fastest and also the least cost 
      effective. It requires a dedicated physically diverse protection 
      path for each working path. Physically diversity could have 
      different meanings depending on the degree of threat to be 
      protected against. It can be node disjoint, link disjoint and span 
      disjoint. SRLG could be assigned to physical link by operators to 
      meet different requirements. For example, an operator can assign 
      physical links passing same disaster zone the same SRLG ID to 
      guarantee services even in case of catastrophic disasters such as 
      earthquakes, and floods.

   -- Shared protection
      Shared protection is fast and more cost effective than dedicated 
      protection. In this case, multiple paths could share the same 
      reserved protection sections (not necessarily paths). However, this 
      requires more information to be distributed in the network and 
      complicated algorithms. A scalable, effective and efficient 
      solution needs to be designed. 

   -- Auto-rerouting
      Auto-rerouting is a non-preplanned protection. No dedicated resource     
      is reserved for working paths. A protection path is created after 
      detecting the failure of a working LSP. The auto-rerouting doesn't 
      need to wait for network topology convergence. A new path can be 
      created by excluding failed nodes in case that they can be 
      identified on-the-fly.  Alternatively, when failures cannot be 
      precisely located on-the-fly, a new path can be created  simply by 
      excluding all nodes along the failed path.


   5.4.4 Circuit LSP Verification
   
   Serving as transport backbone, circuit LSPs are normally required to 
   be strictly verified before delivering to customers. 




Y. Xu et al.                                                      Page [27]

Internet Draft          GMPLS Architecture for ASTN               March 2001


   For ASTN, some verification procedures can be automated. After a 
   circuit LSP is created, OAM&P signals or simulated user traffic can 
   be inserted and tested to verify against path connectivity, constraints 
   and some aspects of SLA.


   5.4.5 Control Plane Failure Handling

   Failures may happen at both the control plane and the transport 
   plane. Many current MPLS mechanisms have the assumption that control 
   plane failure indicates transport plane failure because control 
   traffic and data traffic are mixed together in the same physical path 
   in IP network. So MPLS signaling mechanisms require existing LSPs to 
   be torn down in case of control plane failure. This is undesirable 
   for circuit switched network, where control plane and transport plane 
   may be separated and circuit LSPs are usually backbones for user 
   traffic. One way to handle control plane failures is to keep current 
   circuit LSPs in operation but abort requests that are being processed.
   
   Details for performing graceful control plane failure handling and 
   recovery need to be furthered studied. For example, notification 
   messages should be extended for both types of failures. Also control 
   plane recovery mechanism should be introduced. In case that a NE 
   controller recovered, it may need to consult with its neighbors to 
   synchronize link state information and current LSPs status.

   With control plane taking over many responsibilities from the 
   management plane, control plane failure also has significant impact 
   on management plane. For example, the billing system may rely on NE 
   control entity for resource usage information. Details of these 
   implications need to be further studied.


6. Security Considerations

   Security is critical where different business domains interact. When 
   service invocations happen between business domains, encryption and 
   authentication mechanisms are required at the service interfaces. 
   Within a single business domain, strict security needs further study. 
   However, the control plane network should be isolated from user traffic 
   to avoid sensitive information being leaked out. Many details need 
   further study. 


7. Intellectual Property

   The IETF has been notified of intellectual property rights claimed in
   regard to some or all of the specification contained in this document.  For 
   more information consult the online list of claimed rights.



Y. Xu et al.                                                      Page [28]

Internet Draft          GMPLS Architecture for ASTN               March 2001


8. Acknowledgment

   The authors would like to thank Patrice Lamy, Wyley Robinson, George 
   Newsome, John Ellson, Harvey Epstein, Zhi-wei Lin, Siva Sankaranarayanan, 
   Dave Chen, and Girish Pahlya for their helpful suggestions and comments 
   on this work.


9. Authors' Addresses

    Yangguang Xu
    21-2A41, 1600 Osgood Street
    Lucent Technologies, Inc.
    North Andover, MA 01845
    Email: xuyg@lucent.com

    Eve Varma
    3C 509, 101 Crawfords Corner Rd
    Lucent Technologies, Inc.
    Holmdel, NJ  07733-3030 
    Email: evarma@lucent.com

    Ramesh Nagarajan
    3M-335, 101 Crawfords Corner Rd.
    Lucent Technologies, Inc.
    Holmdel, NJ 007733
    Email: rameshn@lucent.com

    Rudy Hoebeke 				
    Alcatel 				
    Francis Wellesplein 1, 		
    2018 Antwerp, Belgium 		
    Email: rudy.hoebeke@alcatel.be 	

    Hirokazu Ishimatsu
    Japan Telecom Co. Ltd.
    2-9-1 Hatchobori, 
    Chuo-ku, Tokyo, 104-0032 Japan
    E-mail: hirokazu@japan-telecom.co.jp

    Osama S. Aboul-Magd 			
    Nortel Networks 				
    P.O. Box 3511, Station "C" 		
    Ottawa, Ontario, Canada 			
    K1Y - 4H7  
    Email: osama@nortelnetworks.com 	






Y. Xu et al.                                                      Page [29]

Internet Draft          GMPLS Architecture for ASTN               March 2001
    

    Michael Mayer
    Nortel Networks
    P.O. Box 402    
    Ogdensburg NY 13669    
    Email: mgm@nortelnetworks.com 

    Daniel O. awduche.com
    Movaz
    Email: awduche@movaz.net

    Yong Xue
    Global Network Architecture
    UUNET/WorldCom
    Ashburn, Virginia
    Email: yxue@uu.net 

    Curtis Brownmiller
    WorldCom
    Richardson, TX 75082
    Email: curtis.brownmiller@wcom.com

    John Eaves
    TyCom
    1C-240, 250 Industrial Way West
    Eatontown, NJ 07724
    Email: jeaves@tycomltd.com

    Raj Jain
    Nayna Networks, Inc.
    157 Topaz St.
    Milpitas, CA 95035
    Email: raj@nayna.com

    Guangzhi Li
    AT&T
    Email: gli@research.att.com>
















Y. Xu et al.                                                      Page [30]

Internet Draft          GMPLS Architecture for ASTN               Nov. 2000


10. References

[MPLambdaS] D. Awduche, etc. al., "Multi-Protocol Lambda Switching: Combining 
            MPLS Traffic Engineering Control with Optical Crossconnects", draft-
            awduche-mpls-te-optical-02.txt, Work in Progress, July 2000.

[MPLS-ARCH] E. Rosen, et. al. "Multiprotocol Label Switching Architecture", 
            draft-ietf-mpls-arch-07.txt, Work in Progress, July 2000.

[MPLS-TE]   D. O. Awduche et al., "Requirements for Traffic Engineering over 
            MPLS", RFC 2702, September 1999.

[GMPLS-SIG] P. Ashwood-Smith, et al., "Generalized MPLS - Signaling Functional 
            Description", draft-ietf-MPLS-generalized-mpls-signaling-01.txt, 
            Work in Progress, Nov. 2000.

[OPT-BUND]  B. Rajagopalan, et al., "Link Bundling in Optical Networks", draft-
            rs-optical-bundling-01.txt, Work in Progress, September, 2000.

[AND]       H. Koay, Y. Xu, "Automatic Neighbor Discovery for Optical 
            Networks", draft-koay-mpls-and-optical-00.txt, Work in Progress, 
            Sept,2000

[LMP}       J. Lang, et al., " Link Management Protocol", draft-ietf-mpls-lmp-
            00.txt, Work in Progress, September, 2000.

[ND-OIF]    G. Bernstein, et al., "Methods for Neighbor Discovery in SONET & 
            SDH", OIF2000-159, August, 2000.

[OLCP]      A. Chiu, et al., "Unique Features and Requirements for The Optical 
            Layer Control Plane", draft-chiu-strand-unique-OLCP-00.txt, Work in          
            Progress, July 2000.

[LSP-HIER]  K. Kompella et al., "LSP Hierarchy with MPLS TE", draft-kompella-
            lsp-hierarchy-01.txt, Work in Progress, Nov. 2000.

[IPO-FRAM]  B. Rajagopalan, et al., "IP over Optical Networks: A Framework", 
            work in progress, July, 2000

[DIST-AREA] Y. Hayata, et al., "Carrier needs regarding survivability 
            and maintenance of switched optical networks", draft-hayata-ipo-
            carrier-needs-00.txt, Work in Progress, June, 2000.

[OSPF-OMPLS]K. Kompella, et al., "OSPF Extensions in Support of MPL(ambda)S", 
            draft-kompella-ospf-ompls-extensions-00.txt, Work in Progress, June, 
            2000.

[ISIS-OMPLS]K. Kompella, et al., "IS-IS Extensions in Support of MPL(ambda)S", 
            draft-kompella-isis-ompls-extensions-00.txt, Work in Progress, June, 
            2000.


Y. Xu et al.                                                      Page [31]

Internet Draft          GMPLS Architecture for ASTN               Nov. 2000


[CARR-REQ]  Y. Xue, M. Lazar, "Carrier Optical Services Framework and 
            Associated Requirement for UNI", OIF2000-155, Work in Progress, Oct, 
            2000.

[ON-REST]   B. Doshi et al., "Optical Network Design and Restoration," Bell Labs 
            Technical Journal, Vol. 4, No. 1, Jan-Mar 1999.

[DISJ-PATH] J. W. Suurballe, "Disjoint Paths in a Network," Networks, Vol. 4, 
            1974, pp. 125145.











































Y. Xu et al.                                                      Page [32]