Internet Draft


Network Working Group                                  D. Papadimitriou
Internet Draft                                                 J. Jones
draft-papadimitriou-enhanced-lsps-01.txt                        Alcatel
Expiration Date: May 2001
                                                          November 2000


                         Enhanced LSP Services


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."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   This document describes G.LSP parameters and attributes as well as
   the enhanced services they support. In the scope of the domain
   service model, this draft covers the User-to-Network Interface (UNI)
   parameters and the specific parameters used within Network-to-
   Network Interface (NNI) signaling. We propose to group these
   parameters in three distinct groups: G.LSP Identification
   parameters, G.LSP Service parameters and Policy parameters. The main
   objective of this proposal is to integrate within the G.LSP
   parameters the Virtual Private optical Network (VPoN) model, the
   class-of-priorities and the Class-of-Service (CoS) augmented model
   as well as enhanced protection mechanism and signaling security
   levels.










Papadimitriou et al.       Expires May 2001                          1

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

1. Introduction

   Current IP protocols extensions for services (Integrated or
   Differentiated), for traffic-engineering (Multi-Protocol Label
   Switching), for privacy (Virtual Private Networks), for multicast
   applications (IP Multicast protocols) and for security (IPSec
   Protocol) results from the short-term perspective when the IP
   protocol was defined begin of the eighties. Now, the current
   developments on optical networking are challenging the same problem:
   if these features are not included from the beginning within the
   signaling and routing protocols used in optical networking, future
   needs won't be covered by the current developments.

   The main objective of this proposal is to include within the G.LSP
   parameters and within signaling and routing protocols (for further
   studies) the Virtual Private optical Network (VPoN) model, the
   Class-of-Priorities (CoP) and the Class-of-Service (CoS) augmented
   model, and the multicast G.LSP. Enhancement considered in this
   document cover also the protection and fault-tolerance mechanism as
   well as signaling security levels.

   In order to structure the integration of these features within the
   signaling and routing protocols, we propose a classification
   separating the parameters distributed within an optical sub-network
   (Identification and Service parameters) from the one centralized on
   directory service (Policy-related parameters). This means that we
   consider for scalability, convergence and performance reasons that
   keeping all the policy-related parameters would result in an
   overflow of information to be distributed throughout the optical-
   network giving rise to an increasing convergence time which could
   potentially increase the setup time of a G.LSP. The proposed
   classification and parameter hierarchy takes also into account the
   relationship with status and result codes.

   The remainder of the document is organized as follows:

   Sections 2 _ 4 describe the details of the attributes for
   Identification, Service and Policy groups, respectively. Section 5
   describes result and status codes. Annex 1 defines the terminology
   used in the contribution.

2. Identification parameters

   The following identification-related parameters are considered.
   These parameters belong to Type 0x01. Within this document
   parameters types and sub-types are defined for future use.


2.1 Termination-Point identification parameters (Sub-type 0x01)

   The ONE Termination-point identification parameters apply to both
   the source and the destination of a G.LSP. These definitions could

Papadimitriou et al.       Expires May 2001                          2

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

   be applied also to the CNE end-point identification. Within the
   scope of the Domain Service model, the concepts developed within
   this section are also related to the address registration and
   resolution mechanisms.

2.1.1 Parameters definition

   - Port ID: 16-bit integer indicating and identifying the a port
     within an Optical Network Element _ ONE or Client Network Element
     - CNE

   - Channel ID: 16-bit integer indicating and identifying a channel
     within the specified port ID

   - Sub-Channel ID: 16-bit integer indicating a sub-channel within the
     specified Channel ID

   - Logical-port ID: identifies a logical port; concatenation of the
     port-ID (16-bit field), the Channel-ID (16-bit field) and the Sub-
     channel-ID (16-bit field)

   - Logical-address: the address associated with a logical-port.

     Logical-address could be one of the following:
      - ITU-T E.164 ATM End System Address (AESA): 160-bit field
      - British Standards Institute ICD AESA: 160-bit field
      - ANSI DCC AESA: 160-bit field
      - Ethernet address: 48-bit field
      - IPv4 address: 32-bit field
      - IPv6 address: 128-bit field
      - Default-value: 56-bit field (UNSPECIFIED: 0x0...0)

     The logical-address field (maximum 21-byte field) is constituted
     by the logical-address type sub-field and the logical-address
     value sub-field:
      - the logical-address type is a 8-bit sub-field indicating the
        type of the logical-address (default-value of the logical-
        address type is 0x00).
      - the logical-address value is a variable-length field of maximum
        20 bytes indicating the value of the logical-address (maximum
        20-byte sub-field without justification).

     The default-value (type 0x00) is a 56-bit field to optionally
     indicate the User-Group ID (7-byte field) within this field.
     Consequently, the logical-address of the Client will map a virtual
     identifier corresponding to the User-Group ID to which the G.LSP
     belongs. By using this method, the Virtual Private optical Network
     _ VPoN concept is mainly integrated within the logical addressing
     scheme.

   - Termination-point ID: 80-bit field resulting from the
     concatenation of the unique IPv4 address (32-bit field)

Papadimitriou et al.       Expires May 2001                          3

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

     associated to the device and the logical-port ID (48-bit field)

   - Termination-point address: concatenation of the logical address
     and the termination-point ID.

   Consequently for the Client Network Element (CNE) addressing:
    := 
    := 

   The termination-point ID is a 80-bit field (32-bit IP Address, 16-
   bit Port ID; 16-bit Channel ID, 16-bit Sub-Channel ID). By
   concatenating this value with the logical-address a maximum 248-bit
   field results.

   and for the Optical Network Element (ONE) addressing:
    := 
    := 

   For ONEs that do not associate logical addresses with their
   interfaces, the ONE termination-point address corresponds to the
   UNSPECIFIED value concatenated with the ONE termination-point ID.

2.1.2 Address Registration/Resolution - Overview

   Client logical-address registration mechanism is detailed in
   [OIF2000.261.1]. Concerning the address resolution mechanism, the
   source client needs to send an address resolution request to obtain
   the ONE destination termination-point ID (trusted UNI interface) or
   CNE termination-point ID (untrusted UNI interface) corresponding to
   the destination CNE logical-address. Protocol specifications for the
   address resolution request/response are left for further study.

   Consequently, at a trusted UNI interface, the G.LSP create message
   sent by the CNE to the ONE includes the source and destination ONE
   (or CNE) termination-point IDs requested for this G.LSP. This
   implies that the source ONE must perform a internal address-lookup
   toward a directory service or a local mapping table, in order to
   find the mapping between the destination CNE termination-point ID
   and the destination ONE termination-point ID.

   So, the optical network client only needs to know the CNE source and
   destination logical address and termination-point ID in order to
   request a G.LSP creation; any other topological information
   concerning the optical network termination-point identification is
   transparent for the client.

   This mechanism is also adapted for inter-domain G.LSP [OPTICAL-TEIP]
   since in this case only the autonomous-system (AS) boundary ONE
   termination-point to CNE termination-point mapping-list has to
   announced to the neighboring BGP AS's.

Papadimitriou et al.       Expires May 2001                          4

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000


2.1.3 Address Space Considerations

   By default, the address space is unique within a given optical
   network. This means that all client addresses connected to the same
   optical network must be unique. However, if the optical network
   supports the concept of client identifier (which determines the
   owner of the CNEs connected to the optical network, see section
   2.3), then the address space uniqueness could be limited to logical
   addresses belonging to the same Client ID. This aspect is covered in
   section 2.3.

   In to order to guarantee the uniqueness of the client addressing
   scheme and consequently the uniqueness of the mappings, an
   additional mechanism must be provided during the client address
   registration process. This mechanism includes within the address
   registration response a status message indicating if the mapping
   between the logical-address and the corresponding termination-point
   ID has been registered or rejected.

   If the mapping has been registered, then it means that this mapping
   is unique within the optical network; otherwise if the mapping has
   been rejected it means that either the logical address already
   exists within the optical network or the logical address-type is
   invalid.

   When a duplicated logical address generates a mapping rejection, the
   rejected mapping must be the one coming from the newly non-
   registered address. This is to ensure a non-disruptive service for
   the established G.LSPs already using this mapping. Additional
   mechanisms could be defined to enable logical address mismatch,
   rejection, and error tracking. These mechanisms are left for further
   study.

2.2 Optical network identification parameters (Sub-type 0x02)_

   - The Carrier ID (CID) is a 32-bit field defining the identity of
   the carrier to which the ONE element belongs.

   - The Privacy ID (PrID) determines whether a UNI or a NNI interface
   is untrusted or trusted. Hence, from this point-of-view, we consider
   four kind of interfaces: trusted UNI, untrusted UNI, trusted NNI and
   untrusted NNI interfaces.

   These identifiers are provisioned by the administrative authority of
   the optical network and exchanged during the neighbor identity
   discovery process [ONNI-FRAME].

   The Carrier ID uniquely determines the owner of a signaling message
   when travelling over Inter-Domain NNI (IrDI-NNI) signaling channels
   between optical networks.


Papadimitriou et al.       Expires May 2001                          5

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000


   The Privacy ID makes the distinction between trusted and untrusted
   NNI interfaces: generally, there is a trust relationship between
   Intra-Domain (IaDI-NNI) interfaces and an untrusted relationship
   between IrDI-NNI interfaces. The privacy level (trusted or
   untrusted) defines the confidentiality level of the information
   exchanged through the corresponding NNI interfaces.

2.3 Client identification parameters (Sub-type 0x03)

2.3.1 Parameters definition

   The client identification parameters include the Client Identifier
   (Client ID) and the User-Group Identifier (User-Group ID).

   - Client ID: 32-bit integer (provided by the client) which
     uniquely identifies a client (i.e. a group of client CNE belonging
     to the same administrative authority) against the optical network
     domain.

     The client ID corresponds to a client identifier which uniquely
     determines the client identity against an optical network domain.
     This parameter should not have any complex semantic nor meaning.

     Note that the client identifier is not equivalent to the
     Contract ID parameter defined in [OIF2000.61.5]. In this proposal,
     the Contract ID parameter is defined in section 4.3.

   - User Group ID: 7-bytes field structure based on the VPN
     identifiers [VPN-ID]

     The source and destination ONE are responsible for authentication
     of User-Groups and for call acceptance policies. In the absence of
     a pre-determined policy, the default behavior is for the
     destination CNE to accept the G.LSP create request if the
     destination CNE is part of the signaled and authenticated User-
     Group.

     Since a boundary ONE can potentially be connected to multiple
     client CNEs, or a given client CNE can potentially request G.LSP
     for different groups of users, this identifier defines the
     possibility to setup Virtual Private optical Networks (VpoN). The
     corresponding models can be described as follows:

2.3.2 VPoN Models

   The VPoN - Virtual Private optical Network models considered here
   are based on the following concepts:
    - the client-ID defines the identification of an optical network
      client (for instance, an ISP)
    - the user-group-ID defines the identification of a group defined


Papadimitriou et al.       Expires May 2001                          6

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

      within this optical network client (for instance an ISP client)

   The first model considers the Client-ID as a potential VPoN
   identifier the second one considers only the User-Group ID as a
   potential VPoN identifier.

   If we consider the Client-ID as a potential VpoN identifier, then
   the following alternative could be considered:
   - isolation of the resources within a given user-group (for
   instance, a given ISP client)
   - isolation of the resources between user-groups within a given
   client-ID (for instance, between ISP clients belonging to the same
   ISP)
   - no-isolation of the resources i.e. sharing of the resource between
   clients within the optical network

   In this example, the optical network has several clients (i.e. ISPs
   identified by a unique Client ID) and each of the optical network
   clients has several clients (i.e. ISP clients identified by a unique
   User-Group ID).

   If we only consider the User-Group ID as a potential VpoN
   identifier, then the following alternative could be considered:
   - isolation of the resources within a given user-group (for
   instance, a given ISP)
   - no-isolation of the resources i.e. sharing of the resource between
   user-groups within the optical network

   In this example, the optical network has several clients (i.e. ISPs
   identified by a unique User-Group ID) and there is no dependence of
   the isolation regarding the owner of the VPoN.

2.3.3 VPoN and Address Space

   If we consider one unique address space per optical network, this
   means that any address belonging to any VPoN must be unique.
   Otherwise, if we consider on address space per VPoN (for instance,
   per Client ID), then the address uniqueness is limited to this VPoN.

   The last case is most flexible since it permits to connect client
   having overlapping address spaces. However, this also requires for
   the optical network to maintain one mapping table per Client ID.

2.4 G.LSP identification parameters (Sub-type 0x00)

   The G.LSP Identifier (G.LSP ID) is the unique identifier of the
   G.LSP assigned by the optical network. The G.LSP ID is coded as a
   64-bit field obtained from the concatenation of two fields uniquely
   identifying the G.LSP within an optical network:
    - IPv4 address of the source ONE considered as an unique IP address
      inside a given optical network
    - 32-bit integer assigned by the source ONE. This integer is

Papadimitriou et al.       Expires May 2001                          7

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

      locally unique within a given ONE. (Source Termination point ID
      can be used for this purpose)

   G.LSP ID is assigned by the source ONE in response to a G.LSP
   create request. Within the G.LSP create message (sent by the client
   CNE), the UNSPECIFIED value is assigned to the G.LSP ID.

   However, an additional distinction could be suitable when
   considering untrusted interfaces. In this case, the IPv4 address is
   replaced by the Carrier ID in order to hide the ONE identifier (ONE
   IPv4 address) from the client network.

   G.LSP ID reserved values are as follows:
    - UNSPECIFIED value: 0x0...0 referring to a not-specified G.LSP ID
    - ALL value: 0xF...F referring to all the G.LSP IDs

3. Services parameters

   Concerning the G.LSP services, the basic G.LSP services, the G.LSP
   protection and G.LSP routing parameters are considered. These
   parameters belong to Type 0x02.

3.1 G.LSP services parameters (Sub-type 0x00)

   G.LSP service parameters concerning Framing-Bandwidth and SDH/Sonet
   are different from those proposed in [GMPLS]. Other parameters
   considered within this sub-section, offers the possibility to
   implement the enhanced services proposed as main objective of this
   proposal.

3.1.1 Framing-Bandwidth

   The Framing-Bandwidth parameter is defined as an integer specifying
   the format and the associated bandwidth of the signal transported
   across the UNI and represents the framing and bandwidth of the
   service requested through the optical network.

   This parameter is a 16-bit integer constituted by a framing type
   (4-bit sub-field) and an associated bandwidth (12-bit sub-field)

   Framing-type (4-bit sub-field) possible values are:
      - Clear channels : type 0x0
      - Sonet          : type 0x1
      - SDH            : type 0x2
      - PDH            : type 0x3
      - WAN Ethernet   : type 0x4
      - LAN Ethernet   : type 0x5
      - Digital Wrapper: type 0x6

   Bandwidth (12-bit sub-field) possible values are:



Papadimitriou et al.       Expires May 2001                          8

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

      - Clear Channels: possible values are coded as OC-
        where N = 0x001 (OC-1) to N = 0xC00 (OC-3072)

      - Sonet: possible values are coded as OC- or VT-
        where N = 0x001 (OC-1) to N = 0xC00 (OC-3072)
        or N=0xF01 (VT1.5), N=0xF02 (VT2), N=0xF03 (VT3), N=0xF06 (VT6)
           N=0xF04 (OC-1), N=0xF05 (OC-3c), N=0xF06 (OC-12c),
           N=0xF07 (OC-48c), N=0xF08 (OC-192c), N=0xF09 (OC-48 Line)
           N=0xF0A (OC-192 Line), N=0xF0B (OC-48 Section),
           N=0xF0C (OC-192 Section)

      - SDH: possible values are coded as STM- or VC-
        where N = 0x001 (STM-1) to N=0x400 (STM-1024)
        or N=0xF01 (VC-11), N=0xF02 (VC-12), N=0xF03 (VC-2),
           N=0xF04 (VC-3), N=0xF05 (VC-4), N=0xF06 (VC-4-4c),
           N=0xF07 (VC-4-16c), N=0xF08 (VC-4-64c), N=0xF09 (MS-16)
           N=0xF0A (MS-64), N=0xF0B (RS-16), N=0xF0C (RS-64)

      - PDH: possible values are DS- - E- - J-
        where DS = 0x1 - E = 0x2 - J = 0x3 and N = 0x01 to 0x04
        So, DS-0 = 0x101 and PDH DS-0 = 0x3101 etc.

      - WAN Ethernet: possible value 10 Gbps: 0x3E8

      - LAN Ethernet: possible values are coded in 10 Mbps units
        So, 10 Mbps = 0x001 - 100 Mbps = 0x00A
            1 Gbps = 0x064 - 10 Gbps = 0x3E8

      - Digital Wrapper: possible values are coded in 2.5 Gbps units
        So, 2.5 Gbps = 0x001 - 10 Gbps = 0x004 - 40 Gbps = 0x028

      Note: Digital Wrapper refers to Standard Digital Wrapper layer as
            proposed by the ITU-T G.709 v0.83 proposal [ITU-T G.709].

3.1.2 SDH/Sonet Parameter

   The SDH/Sonet parameter (16-bit integer) applies only to SDH/Sonet
   framing. This parameter includes the Transparency levels (4 MS Bits)
   and the Concatenation types (next 4 Bits); the last byte is left
   unused for future use.

   Transparency: Possible values are coded on 4-bit integer:
      - Default-value                         = 0x0
      - PLR-C (Physical Layer Regeneration)   = 0x1
      - STE-C (Section Terminating Equipment) = 0x2
      - LTE-C (Line Terminating Equipment)    = 0x3

   In PLR-Circuits (type 0x0), all SDH/Sonet overhead bytes are left.
   unchanged when transported between clients over the optical network.
   STE-Circuits (type 0x1) preserves all SDH/Sonet line. overhead bytes
   between clients but the section overhead bytes are not required to
   be preserved. LTE-Circuits (type 0x3) preserves the SDH/Sonet

Papadimitriou et al.       Expires May 2001                          9

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

   payload but the section and line overhead bytes are required to be
   preserved.

   Concatenation: Possible values are coded on 4-bit integer:
      - Default-value (no concatenation)      = 0x0
      - Virtual Concatenation                 = 0x1
      - Continuous Concatenation              = 0x2

3.1.3 Optical Parameter

   The optical parameter is related to all-optical network. Since
   SDH/Sonet framing is currently the key consideration, this parameter
   should be not included within the G.LSP service requests (even
   optionally).

   This 32-bit parameter is divided in two parts; both defines the
   maximum admitted value for an optical signal-related parameter:

   - Bit Error Rate: 8-bit integer defining the exponent of the
     maximum BER admitted for a given optical signal (default value:
     0x00)
   - Jitter: 8-bit integer defining the maximum jitter admitted for a
     given optical signal (default value: 0x00)

3.1.4 Directionality

   The directionality parameter is an 8-bit integer indicating the
   directionality of the G.LSP. If this optional parameter is omitted,
   the G.LSP is assumed to be bi-directional.

   Possible values are: - uni-directional   = 0x01
                        - bi-directional    = 0x11 (default value)
                        - multi-directional = 0xmn

   Multi-directionality concept is related to point-to-multipoint
   G.LSPs established throughout the optical network. In this case, one
   source could have till 256 destinations. Optical mutlicast is for
   further study.

3.1.5 Priority-Preemption and CoS Augmented Model

   The priority-preemption is an optional parameter defined as a 16-bit
   integer including the priority (12-bit integer) and preemption level
   (4-bit integer) of a G.LSP:

   1. Priority

   Priority is a 12-bit integer indicating the priority of the G.LSP:
     - Default value: from 0xEF (higher) to 0x10 (lower)
     - Priorities from 0xF0 to 0xFF are reserved
     - Priorities from 0x0F to 0x00 are reserved


Papadimitriou et al.       Expires May 2001                         10

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

   Where  (4 MS bits) defines the priority-class: C ranges from 1 to
   E Class 1 is considered as the default class and Class 0 and Class F
   are Reserved priority-classes. The priority value (8 LS bits) within
   a given priority-class ranges from 0xEF (higher priority) to 0x10
   (lower priority).

   The CoS augmented model [DIFF-ARCH] is based on the following
   principle: at the boundary CNE, if we consider Packet-Switch Capable
   (PSC) interfaces, the DiffServ Codepoint (DSCP) [DIFF- DSF] defining
   the Per Hop Behaviour (PHB) [DIFF-PHB], are mapped to the G.LSP
   priority class. For this purpose, we propose the following rules:
     - Class 1 corresponds to Best-Effort service
     - Class 2 to D corresponds to Assured Forwarding (AF) services
        . Class AF1 ranges from 2 to 4
        . Class AF2 ranges from 5 to 7
        . Class AF3 ranges from 8 to A
        . Class AF4 ranges from B to D
     - Class E corresponds to Expedited Forwarding (EF) service

   These DiffServ classes are related within the optical network to the
   service-level defined in section 3:
     - Class 1 defines a best-effort service
     - Class 2 to 7 defines a bronze service
     - Class 8 to D defines a silver service
     - Class E defines a gold service

   Within our definition of G.LSP, the analogy between the drop
   precedence in DiffServ and the priority class could also be related
   to the preemption setting at the UNI during the G.LSP creation. In
   this case, the priority value setting is performed through the
   following rules:
     - Class 1 defines a priority ranging from 0x110 to 0x1EF
     - Class 2 to 7 defines a priority ranging from 0x210 to 0x7EF
     - Class 8 to D defines a priority ranging from 0x810 to 0xDEF
     - Class E defines a priority ranging from 0xE10 to 0xEEF

   2. Preemption

   Preemption is a 4-bit integer indicating the preemptability of an
   G.LSP. This parameter specifies whether a given G.LSP can be
   preempted by a G.LSP of higher priority if the resource used by the
   lower-priority G.LSP need to be used during the setup and/or the
   recovery of this higher priority G.LSP.

   The possible values for the preemption (4 bit-field) are:
     - Setup and Recovery preemptability: 0x0 (Class 1)
     - Recovery preemptability          : 0x1 (Class 2 to 7)
     - Setup preemptability             : 0x2 (Class 8 to D)
     - No_preemptability                : 0x3 (Class E)




Papadimitriou et al.       Expires May 2001                         11

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

   Two VpoN models have been defined, the priority-preemption levels
   considered here are directly related to these models and the
   resource isolation concept described in section 2.3.

   If we consider the Client-ID as a potential identifier, then we have
   the following options concerning the preemption levels:
     - preemption within a given user-group (i.e within VpoN belonging
       to the same optical network client)
     - preemption within a given client-ID (i.e between VpoN
       belonging to the same optical network client)
     - preemption between client-Ids (i.e between optical network
       clients)

   If we do not consider the Client-ID as a potential identifier, then
   we have the following options concerning the preemption levels:
     - preemption within a given user-group (i.e within VpoN belonging
       to the same optical network client)
     - preemption between user-groups (i.e between VpoN belonging to
       the separate optical network client)

3.1.6 Bundles

   The corresponding encoding and semantic is left for further study.

3.1.7 Maximum Signaling Delay

   The Maximum Signaling Delay is 4-byte parameter specifying a limit
   to the maximum acceptable propagation delay (units in milliseconds)
   for the network to process the client requests. The Maximum
   Signaling Delay parameter is optional.

   Default value: infinite

3.2 G.LSP protection parameters (Sub-type 0x01)

   Protection parameter indicates the protection level desired for the
   G.LSP inside to the optical network (internal protection) or at the
   UNI (source- and destination-side protection levels) which the
   protection level requested between both side of the client-to-
   network connection.

   This optional parameter indicates the protection type (4-bit
   integer) requested by the client device from:
    - the optical network: internal network protection (type 0x1)
    - the source drop-side: source-side protection (type 0x2)
    - the destination drop-side: destination-side protection (type 0x3)
    - no protection (default-value: 0x0)

   For each of these protection types, the protection levels (8-bit
   integer) defined are the following:



Papadimitriou et al.       Expires May 2001                         12

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

    - Internal Protection (or Network Protection):
       . Unprotected              - type 0x00 (default value)
       . Dedicated 1:1 Protection - type 0x10
       . Shared Protection M:N    - type 0x20
       . Dedicated 1+1 Protection - type 0x30

    - Source-Side Protection (protection between CNE and ONE on source
      side):
       . Unprotected              - type 0x00 (default value)
       . Dedicated 1:1 Protection - type 0x10
       . Shared Protection M:N    - type 0x20
       . Dedicated 1+1 Protection - type 0x30

    - Destination-Side Protection (protection of between CNE and ONE on
      destination side):
       . Unprotected              - type 0x00 (default value)
       . Dedicated 1:1 Protection - type 0x10
       . Shared Protection M:N    - type 0x20
       . Dedicated 1+1 Protection - type 0x30

   Internal-network- and Side- protection the last 4-bit sub-field
   indicates the protection-scheme of the G.LSP: inherent (0x30) or
   non-intrusive (0x31), quality-class values are TBD.

   Related to these protection types and levels, a reversion strategy
   (4-bit integer) could be defined:
    - a revertive strategy (type 0x0) means that a G.LSP gets restored
      to its original route after a failure has been recovered or
      repaired
    - a non-revertive strategy (type 0x1) means that a G.LSP does not
      get restored to its original route after a failure has been
      recovered or repaired

3.3 G.LSP routing parameters (Sub-type 0x02)

3.3.1 Routing Diversity

   The routing diversity of a G.LSP is defined as the list of N G.LSPs
   ID from which a given G.LSP (so a given G.LSP ID) must be physically
   diverse from.

   Based on the hierarchy specified in the [OIF2000.019] OIF
   Contribution, the Diversity of a G.LSP takes into account the
   following types:
      - Shared Risk Link Group: Resource type: 0x00 (default value)
      - Fiber segment         : Resource type: 0x01
      - Fiber sub-segment     : Resource type: 0x02
      - Fiber link            : Resource type: 0x03
      - Optical device        : Resource type: 0x04

   Resource IDs are defines as follows:
      - Fiber segment         : List of fiber sub-segments

Papadimitriou et al.       Expires May 2001                         13

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

      - Fiber sub-segment     : List of fiber links
      - Fiber link            : 
      - Optical device        : ONE IPv4 Address
      - Shared Risk Link Group: 0x00 (default value)

   Diversity is considered here for both unidirectional and bi-
   directional G.LSPs. This means that even if two-half G.LSP as put
   together to form a bi-directional G.LSP diversity applies to both
   halves.

   So the diversity parameter could be implemented as variable-size
   list:
     - Exclude: G.LSP ID 1 (64-bit) - Resource type - Resource ID
     - ...
     - Exclude: G.LSP ID N (64-bit) - Resource type - Resource ID

   Note that the SLRG of a G.LSP is the SRLGs union of the links
   covered by the G.LSP. SRLG encoding should be further discussed: a
   first approach would be an ordered or unordered list of the SRLG
   values to which the G.LSP belongs.

   When executing the G.LSP service request from the client CNE (remind
   here that the client CNE does only knows about the G.LSPs he has
   already established) the client CNE can only reference a G.LSP M
   from which the new G.LSP N should be diverse. The ONE will interpret
   this request by considering the Shared Risk Link Group (SRLG) of the
   G.LSP M and find a physical route for the G.LSP N whose SRLG is
   diverse from.

   The same process applies at the IrDI-NNI interface where the
   outgoing ONE (belonging to the BGP AS i) does only knows about the
   G.LSPs he has already established to the incoming ONE (belonging to
   the BGP AS j). Consequently, the outgoing ONE can only reference a
   G.LSP M from which the new G.LSP N should be diverse.

3.3.2 Explicit Route

   Explicit route parameter applies only at the NNI. However, this
   parameter could be used at the UNI within the scope of the Domain
   Specific Routing model.

   The semantic of the explicit route parameter is detailed in [ONNI-
   FRAME]. The detailed structure of this parameter is left for further
   study.

3.3.3 Record Route

   Record route parameter applies only at the NNI. However, this
   parameter could be used at the UNI within the scope of the Domain
   Specific Routing model.



Papadimitriou et al.       Expires May 2001                         14

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

   The semantic of the record route parameter is detailed in [ONNI-
   FRAME]. The detailed structure of this parameter is left for further
   study.

3.4 Identification and Service Parameters - Summary

   The following table summarizes the Identification and Service
   parameters at the UNI interface within G.LSP service requests:

   --------------------------------------------------------------------
   Identification Parameters    Size          Default value   Status
   --------------------------------------------------------------------
   Termination-point ID (ONE)   80 bits       0x0...0  Mandatory(Trust)
   Termination-point ID (CNE)   80 bits       0x0...0  Mandatory(Untr.)
    or Logical Address (CNE)    max 248 bits
   Client ID                    32 bits                       Mandatory
   User-Group ID                56 bits                       Mandatory
   G.LSP ID                     64 bits       0x0...0         Mandatory
   --------------------------------------------------------------------
   G.LSP Service Parameters     Size          Default value   Status
   --------------------------------------------------------------------
   Framing-Bandwidth            16 bits                       Mandatory
   SDH/Sonet Parameter          16 bits       0x0000     Mandatory(TDM)
   Optical Parameter            32 bits       0x0...0        Future use
   Directionality               8 bits        0x11             Optional
   Priority-Preemption          16 bits       0x1EF0           Optional
   Max Signaling Delay          32 bits       0xF...F          Optional
   Internal Protection          16 bits       0x0000           Optional
   Side Protection              16 bits       0x0000           Optional
   Diversity                    Variable                       Optional
   --------------------------------------------------------------------

   The following table summarizes the Identification and Service
   parameters at the NNI interface within G.LSP service requests:

   --------------------------------------------------------------------
   Identification Parameters    Size       Default value      Status
   --------------------------------------------------------------------
   Termination-point ID (ONE)   80 bits    0x0...0            Mandatory
   Carrier ID                   32 bits    0x0...0  Mandatory(IrDI-NNI)
   User-Group ID                56 bits                       Mandatory
   G.LSP ID                     64 bits    0x0...0            Mandatory
   --------------------------------------------------------------------
   G.LSP Service Parameters     Size       Default value      Status
   --------------------------------------------------------------------
   Explicit-Route               Variable                      Mandatory
   Framing-Bandwidth            16 bits                       Mandatory
   SDH/Sonet Parameter          16 bits     0x0000       Mandatory(TDM)
   Optical Parameter            32 bits     0x0...0          Future use
   Directionality               8 bits      0x11               Optional
   Priority-Preemption          16 bits     0x1EF0             Optional
   Max Signaling Delay          32 bits     0xF...F            Optional

Papadimitriou et al.       Expires May 2001                         15

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

   Internal Protection          16 bits     0x0000             Optional
   Side Protection              16 bits     0x0000             Optional
   Diversity                    Variable                       Optional
   Record-Route                 Variable                       Optional
   --------------------------------------------------------------------

4. Policy parameters (Type: 0x03)

   Policy-related parameters are related to directory services provided
   to the client CNE through the UNI services. These parameters include
   the following items:
    - Service-Level parameters
    - Schedule parameters
    - Contract parameters
    - Billing parameters
    - Optional parameters

   These parameters are referred as type 0x03 parameters. By receiving
   such kind of parameters the source boundary ONE needs to forward the
   content of these request through the NMI interface (interface
   between the ONE and a management server) to a centralized directory
   service.

4.1 Service-level parameters (Sub-type: 0x01)

   Service level (i.e. service-level specification) parameter is
   implemented as a 16-bit integer which refer to parameters detailed
   in the previous sub-section (service-related parameters). This
   parameter indicates the class-of-service offered by the optical
   network carrier.

   The first 256 values (0 _ 255) are reserved for future OIF inter-
   operability agreements. The remaining values are carrier specific.

   The service-level parameter could include the following attributes:
    - Priority and Preemption
    - Propagation Delay
    - Protection parameters
    - Routing parameters
    - Signaling security levels

   For instance, value 0x1xxx might indicate through a request to a
   directory service, a best-effort service:
    - unprotected G.LSP
    - default priority
    - infinite propagation delay
    - no routing diversity
    - no signaling authentication

   Value ranging from 0x2xxx to 0x7xxx to might indicate through a
   request to a directory service, a bronze service:
    - M:N protected G.LSP

Papadimitriou et al.       Expires May 2001                         16

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

    - low-priority
    - infinite propagation delay
    - no routing diversity
    - signaling authentication (no signaling encryption)

   Value ranging from 0x8xxx to 0xDxxx to might indicate through a
   request to a directory service, a silver service:
    - M:N protected G.LSP
    - medium-priority
    - infinite propagation delay
    - no routing diversity
    - signaling authentication (no signaling encryption)

   Value 0xExxx might indicate through a request to a directory
   service, a gold service:
    - 1:1 protected G.LSP
    - high-priority
    - finite propagation delay
    - global routing diversity
    - signaling authentication and encryption

   Consequently, this means that the client knows the meaning of the
   service-level prior to the corresponding G.LSP service request.
   Within the G.LSP request, explicit parameter values take precedence
   over service-level.

4.2 Schedule parameters (Sub-type: 0x02)

   Scheduling refers to the possibility to create, delete or modify
   G.LSP through a given time-of-day, day-to-day, day-to-week, etc.
   scheduling plan.

   For a given plan, the scheduling functions could be start, stop and
   repeat.

   The attributes of the scheduling function could be:
    - the start/stop time at which the function has to be
      executed/stopped
    - the start/stop date at which the function has to be
      executed/stopped
    - the recurrence interval between two repeated execution of the
      function
    - the number of recurrence intervals

   The default values of the schedule parameter regarding the G.LSP
   requested service:
    - the start time is the current time (start now)
    - the start date is the current date (start now)
    - the recurrence interval is infinite since the G.LSP request has
      to be executed only once
    - the number of recurrence intervals equals zero


Papadimitriou et al.       Expires May 2001                         17

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000


4.3 Contract parameters (Sub-type: 0x03)

   The contract parameter is defined as an identifier (Contract ID)
   whose value corresponds to a 32-bit string [OIF2000.61.5]. The
   semantic proposed for this parameter refers to the policy parameters
   defined in this section. Note that a given Client ID could have more
   than one Contract ID.

4.4 Billing parameters (Sub-type: 0x04)

   The billing parameter refers to the billing client identifier onto
   which the requested services will be charged. A given client ID
   could have more than one billing client identifier.

   An optical network client (a Client ID) may have several clients
   (i.e. User-Groups) and assign to each of them a dedicated billing
   identifier.

   This parameter is implemented as a 16-bit integer. The first 256
   values (0 _ 255) are reserved for future inter-operability
   agreements. The remaining values are carrier specific.

4.5 Optional parameters (Sub-type: 0x05)

   Optional parameters could include Vendor-specific parameters, etc.

   Details concerning these optional parameters are TBD.

   Two options seem feasible for this purpose:
    - either the client CNE knows the content of the policy-related
      parameters without any additional information coming from the
      optical network
    - or the client CNE initiates a G.LSP status request with
      appropriate extensions to request the policy-related parameters
      values to the optical network. So the client learns dynamically
      the service-level offered by the optical network through a
      directory service before initiate a G.LSP create request to the
      ONE. We refer to this as directory services at the UNI.

5. Result and Status codes

   This section describes the Result codes (section 5.1) and Status
   codes (section 5.2).

5.1 Result codes

   Result codes are mandatory fields included in response to G.LSP
   services (this does not preclude the inclusion of other explicit
   parameter value as response to a G.LSP service request).



Papadimitriou et al.       Expires May 2001                         18

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

   Result codes are 16-bit integers: the first sub-field defines the RS
   byte field and the last sub-field indicates the related cause of the
   RS byte value.

   - Result defines the R value (4 MSB bits of the first byte): None
     (R=0) Failure (R=1) or Success (R=2)

   - Requested LP-Service defines the S value (4 LSB bits of the first
     byte): create (S=1), delete (S=2), modify (S=3), or status (S=4)

   So the RS field defines the result of a service request. The RS
   field corresponding to 04 is only used within the Status request
   message.

   The last byte defines the cause of a given result of a G.LSP service
   request. The RS field is concatenated to the following values:
    - Identification
       . G.LSP ID                   : 0x00
       . Source termination-point ID: 0x01
       . Source port ID             : 0x02
       . Source channel-ID          : 0x03
       . Source sub-channel-ID      : 0x04
       . Source user-group ID       : 0x05
       . Destination termin-point ID: 0x06
       . Destination port ID        : 0x07
       . Destination channel-ID     : 0x08
       . Destination sub-channel-ID : 0x09
       . Destination user-group ID  : 0x0A
       . Client ID                  : 0x0B
       . Carrier ID                 : 0x0C
    - G.LSP Services
       . Explicit route             : 0x00
       . Framing-bandwidth          : 0x11
       . SDH/Sonet parameter        : 0x12
       . Optical parameter          : 0x13
       . Directionality             : 0x14
       . Priority-preemption        : 0x15
       . Max signaling delay        : 0x16
       . Network protection         : 0x17
       . Source-side protection     : 0x18
       . Destination-side protection: 0x19
    - Policy-related: TBD

5.2 Status codes

   Status codes are used to indicated the current, or the change status
   of a G.LSP. Status codes are 16-bit integers.

   - The encoding of the status code is the same as Result codes except
     that RS byte is replaced by
      - Active (0x31) and Inactive (0x32) for G.LSP
      - Reachable (0x41) and Unreachable (0x42) for Identification

Papadimitriou et al.       Expires May 2001                         19

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

        parameters
      - Modified (0x51) and Restored (0x52) for G.LSP Services
      - Query all (0x61) and Query (0x62) for Status request queries

   For instance, an Unreachable (or reachable) status code could refer
   to a destination port ID which becomes unreachable (or reachable).
   In the scope of this proposal, this does not always mean that the
   G.LSP attached to this port are inactive since it is potentially
   possible to loss the control of a port without any impact on the
   already established G.LSPs. However, this implies that a new G.LSP
   can not be established to this specific destination port.

6. Security Considerations

   By including within the service-level parameter the signaling
   security level, the proposed document, as detailed in section 4,
   takes into account the security of the client signaling request
   in a build-in manner.

7. References

   1. [DS-DSF] S.Nichols et al., `Definition of the Differentiated
      Services Field (DS Field) in the IPv4 and IPv6 Headers', RFC
      2474, December 1998.

   2. [DS-ARCH] S.Balke et al., `An Architecture for Differentiated
      Services', RFC 2475, December 1998.

   3. [GMPLS] P.Ashwood-Smith et al., `Generalized MPLS - Signaling
      Functional Description', Internet Draft, draft-ietf-mpls-
      generalized-signaling-00.txt, April 2001.

   4. [MPLS-OUNI] B.Rajagopalan et al., `Signaling Requirements at
      the Optical UNI', Internet Draft, draft-bala-mpls-optical-uni-
      signaling-00.txt, April 2001.

   5. [OIF2000.125.2] B.Rajagopalan et al., `User Network Interface
      (UNI) 1.0 Proposal', OIF Contribution, October 2000.

   6. [OIF2000.061.5] J.Yates et al., `User to Network Interface (UNI)
      Service Definition and Lightpath Attributes', OIF Contribution
      61, November 2000.

   7. [OIF2000.188] R.Barry, `Lightpath Attributes Proposal', OIF
      Contribution 188, August 2000.

   8. [OIF2000.197] J.Heiles, `Alignment of the UNI with ITU-T
      Terminology', OIF Contribution 197, September 2000.

   9. [OIF2000.261.1] D.Papadimitriou et al., `Address Registration and
      Resolution Proposal', OIF Contribution 261, November 2000.


Papadimitriou et al.       Expires May 2001                         20

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

   10.[ONNI-FRAME] D.Papadimitriou et al., `Optical NNI Framework and
     Signaling Requirements', Internet Draft, draft-papadimitriou-onni-
     frame-00.txt, November 2000.

   11.[OPTICAL-TEIP] O.Duroyon et al., `G.LSP Service Model framework in
      an Optical G-MPLS network', Internet Draft, draft-duroyon-te-ip-
      optical-01.txt, November 2000.

   12.[VPN-ID] B.Fox and B.Gleeson, `VPN Identifiers', RFC 2685.


8. Acknowledgments

   The authors would like to thank Bernard Sales, Emmanuel Desmet, Hans
   De Neve, Fabrice Poppe, Stefan Ansorge and Gert Grammel for their
   constructive comments.

9. Author's Addresses

   Dimitri Papadimitriou
   Alcatel
   F. Wellesplein 3, B-2018 Antwerpen, Belgium
   Phone: 32 3 240 8491
   Email: Dimitri.Papadimitriou@alcatel.be

   Jim Jones
   Alcatel USA
   3400 W. Plano Pkwy., Plano, TX 75075, USA
   Phone: 1 972-519-2744
   Email: Jim.D.Jones1@usa.alcatel.com























Papadimitriou et al.       Expires May 2001                         21

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000

Appendix 1: Terminology

   The following terms are used in this document. These definitions
   take into account the terminology already defined by the IETF for
   some of the concepts defined here and some are adapted from the OIF
   Forum terminology.

   - Optical Network: a collection of optical sub-networks constituted
   by optical network elements

   - Optical Network Element (ONE): a network element belonging to the
   optical network. An optical network device could be an Optical
   Cross-Connect (OXC), Optical ADM (OADM), etc.

   - Boundary ONE: an optical network element (ONE) belonging to the
   optical network and including an UNI-N interface.

   - Internal ONE: an optical network element internal to the optical
   network (also referred as a termination incapable device) which does
   not include a UNI-N interface.

   - Client Network Element (CNE): a network element belonging to the
   client network. A client network element could be a SONET/SDH ADM, a
   SONET/SDH Cross-connect, an ATM Switch, an Ethernet switch, an IP
   router, etc.

   - Generalized Label Switched Path (G.LSP): point-to-point optical
   layer connectivity with specified attributes (mandatory and
   optional) established between two ONE termination-points in the
   optical network. G.LSPs are considered as bi-directional (and in a
   first phase as symmetric). A G.LSP could be a Fiber Switched path,
   Lambda Switched path or TDM Switched path (Circuit).

   - UNI Client (UNI-C): signaling and routing interface between a
   Boundary CNE and a boundary ONE belonging to an optical network.

   - UNI Network (UNI-N): signaling and routing interface between a
   Boundary ONE and a boundary CNE belonging to a client network.

   - UNI Services: the services defined at the UNI are the following:
     - Neighbor discovery service
     - Service discovery service
     - G.LSP signalling services (create/delete/modify/status)

   - NMI interface: the interface between the ONE controller and the
   centralized management server.

   Concerning the relationship with this terminology and others [ITU-
   T], we consider within this document that the term Client is
   equivalent to User, Optical network to Service provider network,
   Controller to Signaling agent, Trusted to Private and Untrusted to
   Public.

Papadimitriou et al.       Expires May 2001                         22

draft-papadimitriou-enhanced-LSPs-01.txt                 November 2000



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.




































Papadimitriou et al.       Expires May 2001                         23