Subject: draft-oduroyon-te-ip-optical-01.txt

From: Olivier Duroyon <[email-masked]>
Date: Wed, 06 Dec 2000 11:39:23 -0600

I just realized that draft-oduroyon-te-ip-optical-01.txt has not reached the
database yet.
In the meanwhile please find a copy of the second iteration for San Diego.

Sorry for the inconvenience.

Olivier Duroyon
[email-masked]
Alcatel USA
703 679 6415

 Internet Engineering Task Force                          Olivier Duroyon
                                                             Rudy Hoebeke
                                                             Hans De Neve
                                                    Dimitri Papadimitriou
 Internet Draft                                                   Alcatel
 Document: draft-duroyon-te-ip-optical-01.txt               November 2000
 Expiration Date: May 2001

       G.LSP Service Model framework in an Optical G-MPLS network
                    <draft-duroyon-te-ip-optical-01.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."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt.

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

 1. Abstract

    The objective of this draft is to propose an IP service model for a
    non-packet switch capable optical network where G.LSPs are
    dynamically triggered by the IP layer and subsequently advertised
    for IP routing. The business model assumes that several IP service
    domains, some of which represent different administrative entities,
    share the same optical backbone and focuses therefore primarily on
    an overlay model. G-MPLS signaling (refer to [g-mpls]) with UNI
    support is assumed as underlying control plane protocol.

 2. Conventions used in this document

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

 Duroyon et al.             Expires May 2001                          1

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
    this document are to be interpreted as described in RFC2119.

 3. Introduction

    This draft introduces an end-to-end IP service model enabling the
    dynamic management of Generalized Label Switched Paths (G.LSP) by
    means of G-MPLS signaling with User-to-Network Interface (UNI)
    support. A G.LSP is a point-to-point connectivity with specified
    attributes (some of which are mandatory, while others are optional)
    established between two termination points in the optical network.
    A G.LSP could be a fiber switched path, a lambda switched path, a
    TDM switched path (circuit) or a packet-switch capable G.LSP. The
    scope of this draft is restricted to optical networks, which are by
    definition non-packet switch capable. Consequently, G.LSPs are
    restricted to non-packet switch capable G.LSPs, which we hereafter
    refer to as G.LSPs.

    For reasons of definiteness, the optical devices are always
    referred to as Optical Network Elements (ONE) and the IP devices as
    Client Network Elements (CNE). Boundary CNEs and boundary ONEs are
    interconnected through an UNI signaling and routing interface.
    The owner of the UNI interface in the optical domain (UNI-Network
    or UNI-N) is referred to as in the Boundary ONE Controller (ONE-C).
    Its counterpart in the Client Network (UNI-Client or UNI-C) is
    referred to the Boundary CNE Controller (CNE-C).

    The terminology used in the draft attempts to be in line with the
    definitions found in [ip-optical], [ouni-framework] and
    [OIF2000.125.2].

    An overlay use of G-MPLS (UNI support) is appropriate for an
    untrusted environment where several IP service domains,
    representing different administrative entities, share the same
    optical backbone. Moreover, this model seems well suited for a
    network architecture including non-IP devices, e.g., legacy TDM or
    ATM equipment, that interface with the same optical backbone. This
    is however beyond the scope of this draft.

    To distinguish between trusted and untrusted peers, a separate
    definition for a Trusted and Untrusted network interfaces is
    proposed:
    - An Untrusted interface is defined when UNI (respectively NNI)
    interfaces belongs to distinct administrative authorities. For
    instance an UNI interface between a client network element and an
    optical network element belonging to distinct ISPs defines an
    untrusted relationship between the client and the optical network
    element.
    - A Trusted interface is defined when UNI (respectively NNI)
    interfaces belongs to the same administrative authority. For
    instance an NNI interface between two ONEs belonging to the same

 Duroyon et al.             Expires May 2001                          2

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    optical carrier defines a trusted relationship between these
    optical networks elements.

    The service model further assumes that a decision point in the IP
    service domain, e.g., a Traffic Engineering tool (TE tool), will
    trigger a boundary CNE to issue a G.LSP request towards the optical
    domain. The decision point determines the need for a G.LSP on the
    basis of IP Service Level Agreements (IP SLAs) and related
    information, such as for instance load measurements in the IP
    service domain.

    The same TE-tool may also decide about the configuration of Traffic
    Engineering LSPs (TE-LSP), which are by definition Packet-switch
    capable LSPs. For the purpose of IP traffic engineering, TE-LSPs
    are in this case created on top of non-Packet-switch capable
    G.LSPs.

    In the remainder of the document, the terms TE tool or decision
    point are used interchangeably and refer to the IP service domain
    device, capable of triggering G.LSP requests.

 4. IP service model description

    This section outlines the sequence of events that characterize our
    proposed IP service model.

    (1) Configuration

    Configuration consists of installing and configuring interfaces of
    the boundary ONEs and boundary CNEs.

    During this stage of end-points configuration, physical attributes
    of the end-point (as protection attributes of the drop side) are
    also configured. Configuration of the NNI interfaces of the ONEs is
    out of the scope of this draft.

    (2) Neighbor Discovery, Endpoint Registration and Service Discovery

    The objective of Neighbor Discovery is to provide the information
    needed to identify the neighbor identity and neighbor connectivity
    over each link interconnecting a boundary CNE to a boundary ONE.

    Endpoint registration is concerned with registering boundary CNE
    endpoints to the optical network. The registration information
    includes the resource capabilities, closed user group (CUG)
    identification, port reachability information, UNI protection
    capabilities etc. This set of information is critical to enable
    dynamic G.LSP services at the UNI. The endpoint registration
    mechanism enables the end system to register its critical set of
    information so that other end systems can identify its existence
    and network properties.

 Duroyon et al.             Expires May 2001                          3

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    Service discovery is concerned with obtaining the essential
    information about services from the attached optical network that
    are available for the CNE. This information is used by CNEs to
    establish the service environment. The service discovery mechanism
    allows the network element to convey information about available
    services to the end system.

    After finishing neighbor discovery, endpoint registration and
    service discovery, each end system should establish the service
    environment and have sufficient information to generate G.LSP
    service request. These mechanisms complement each other and they do
    not depend on the establishment and use of signaling channels
    between the two parties.

    (3) Optical Service Level Agreements

    Next, the service model consists of negotiating Optical SLAs (O-
    SLA) at optical network-client network boundaries, or between
    optical networks.

    In case of an untrusted peering relationship (i.e. untrusted UNI,
    respectively NNI), each G.LSP request is authenticated and
    validated against the O-SLA. The validation process against an O-
    SLA includes checking whether the request is conforming to the
    restrictions (e.g., on scope) defined in the O-SLA.

    O-SLAs may also be defined at trusted interfaces as the optical
    domain to provision resources that could use them. Trusted in this
    context refers to the fact that you don't expect the CNE to violate
    this O-SLA, and as such requests received from trusted neighbors
    don't need to be validated against the O-SLA.

    (4) G.LSP service request

    The decision point of the client network determines the required
    connectivity through the optical domain based on service
    requirements as per the IP SLAs. It then triggers the boundary CNEs
    to send a G.LSP service request towards the associated boundary
    ONEs, using G-MPLS signaling with UNI support. This process is
    dynamic and may involve, amongst others, the creation of additional
    G.LSPs, the deletion of existing G.LSPs or the modification of
    existing G.LSPs.

    (5) Address resolution

    At the UNI, the G.LSP service request sent by the CNE needs to
    include the ONE source and destination termination-point
    identifiers (in case of trusted UNI interface) or the CNE source
    and destination termination-point identifiers (in case of untrusted
    UNI interface). CNE termination-points should also be considered
    when the G.LSP is established through several optical networks
    belonging to different administrative authorities.

 Duroyon et al.             Expires May 2001                          4

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    Consequently, the source client needs to send an address resolution
    request to obtain the ONE destination termination-point ID or CNE
    termination-point ID corresponding to the CNE destination logical-
    address of the G.LSP service request.

    (6) Optical path selection

    In case a dedicated instance of an IGP is used inside the optical
    transport network, each boundary ONE learns the complete topology
    of the optical domain. A Constraint-based Shortest Path First
    (CSPF) algorithm can then be implemented in the boundary ONEs to
    calculate a route for the G.LSP in line with the constraints
    specified in the request. As an example, the route of a G.LSP may
    depend on the protection requirements or routing constraints
    specified in the G.LSP request. The latter may indicate that the
    requested G.LSP should be routed diversely from other G.LSPs. This
    CSPF algorithm is expected to be quite different from an IP CSPF
    algorithm because of optical networking specific considerations.

    (7) G.LSP advertisement to the IP layer

    As soon as the G.LSPs are lit up, they are advertised to the client
    network. The involved boundary CNEs will either create a new IP
    link and start to exchange routing information (using IGP or eBGP)
    or modify the characteristics of the existing IP link.

    (8) Traffic engineering for optimization of the optical domain

    Optionally, the optical domain may have its own off-line Optical
    Traffic Engineering (O-TE) tool. This tool may be used for
    optimization of resource utilization in the optical network by
    rearranging some G.LSPs.

 5. UNI discovery and registration services

    In order to provide a flexible and end-to-end IP Service model,
    with a minimum set of local provisioning, specific mechanisms and
    procedures have to be defined at the boundary between the client
    and the optical network:
    - to discover neighbors identity and connectivity
    - to register client end-point identity
    - and to discover the supported UNI and network services.

    Transport mechanisms used for the UNI discovery and registration
    services are referenced in [OIF2000.125.2] and [OIF2000.200].

    5.1 Neighbor discovery at the UNI

    The key objective of Neighbor Discovery at the UNI is to provide
    the information needed to identify the neighbor identity (IP
    address associated to the corresponding UNI) and neighbor

 Duroyon et al.             Expires May 2001                          5

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    connectivity over each link connecting the boundary CNE to the
    boundary ONE.

    Neighbor discovery process which is also referred to as the
    Termination-port identity process, provides the following
    information to the boundary CNE and ONE:
    -  the ONE discovers the identity of the client CNE by
       automatically discovering the IPv4 address assigned to the UNI-C
       and the identity of each physical port connected to the CNE
    -  the CNE discovers the identity of to the connected ONE by
       automatically discovering the IPv4 address assigned to the UNI-N
       and the identity of each physical port connected to the ONE

    If the signaling transport mechanism is not explicitly configured,
    the neighbor discovery process ends by the bootstrapping of the
    signaling control-channel used to exchange the information during
    the end-point registration and the service discovery processes.

    5.2 End-point Registration and UNI Service Discovery

    The end-point registration process includes the exchange of
    information between the CNE and ONE for each of the ports and
    logical ports connecting the CNE to the ONE. A logical port defines
    the structure of a physical port by identifying for a given port
    each of the channels included within this port and sub-channels
    included within this channel.

    The UNI Service discovery process includes the exchange of
    resource-related information of the Framing and Bandwidth capacity
    of each of the ports and logical ports connecting the CNE to the
    ONE. Additional parameters, such as the UNI drop-side protection
    attributes (UNI client-side protection and UNI network-side
    protection) and the G.LSP Directionality support could also be
    exchanged during the resource discovery process. For SDH/Sonet
    interfaces, the Transparency levels (STE-C, LTE-C), the client
    support of Virtual Concatenation (VC) and the levels of Continuous
    Concatenation (CC).

    The end-point registration process includes also the address
    registration process [OIF2000.261.1]. The address registration
    process allows the CNE to register the CNE logical addresses
    attached to the CNE Termination-point ID to which corresponds an
    unique ONE Termination-point IDs. A CNE Termination-point ID
    includes the unique IP address associated with the client element
    and the logical-port ID. The logical-port ID comprises the port-ID,
    Channel-ID and Sub-channel-ID as defined in [OIF2000.125.2].

    When the address registration is part of the end-point registration
    process, the CNE associates the CNE Termination-point ID with the
    corresponding logical address and ONE termination-point ID. When
    the CNE does not associate logical addresses with their interfaces,

 Duroyon et al.             Expires May 2001                          6

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    the CNE termination-point ID resolution implies that the boundary
    ONE knows the mappings between the CNE termination-point ID and the
    ONE termination-point ID. This case is considered as a particular
    case where the CNE logical address fields are empty. In this case,
    the value of the logical address could correspond to the user-group
    identifier to which the G.LSP belongs; however, in this particular
    case, the address resolution is always based on the CNE
    termination-point ID.

    Other client identifiers could be exchanged during end-point
    registration process:
    -  the CNE registers the Contract ID attached to a specific element
       and/or interface
    -  the CNE registers the Closed User-Group (CUG) IDs (i.e. User-
       Group ID) attached to a specific client end-point or port

    5.3 Network Service Discovery

    The network service Discovery consists of the G.LSP service-related
    discovery process and a policy related service discovery process.

    During the G.LSP-related service discovery process, the CNE
    registers and/or discovers the parameters related to
    -  SDH/Sonet related services, i.e., the SDH/Sonet Transparency
       levels supported and the Continuous Concatenation levels
       supported
    -  G.LSP Directionality support
    -  Network-side Protection, i.e., the Protection-levels services
       provided by the internal optical network (Unprotected, Dedicated
       1+1 Protection, Dedicated 1:1 and Shared Protection)
    -  G.LSP Priority classes and Preemption levels supported by the
       optical network
    -  G.LSP Diversity options supported by the optical network
    -  Security levels support (IPSec or other authentication
       mechanism) within the signaling used on the control-plane
       throughout the optical network

    The discovery of the Policy-related service may include the
    following parameters:
    -  Service-levels offered by optical network
    -  Scheduling-related service supported by the optical transport
       network and/or the scheduling desired by the client
    -  Billing-related service supported by the optical transport
       network and/or the billing method desired by the client
    -  Vendor-related and Optional parameters

 6. Address resolution

    As stated in section 4.5, the source client needs to send an
    address resolution request to obtain the ONE destination
    termination-point ID (trusted UNI interface) or CNE termination-

 Duroyon et al.             Expires May 2001                          7

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    point ID (untrusted UNI interface) corresponding to the destination
    CNE logical-address.

    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 (cf. Section
    9.1) 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.

 7. Optical Service Level Agreements

    An optical domain-IP service domain boundary coincides with a UNI
    with its associated O-SLA. Similarly, if there are multiple optical
    sub-networks in the optical domain, there will be O-SLAs negotiated
    at each optical sub-network boundary. An optical sub-network
    boundary then corresponds to an optical Network-to-Network
    Interface (NNI). In this draft, we limit the discussion to O-SLAs
    at the level of UNIs.

    As mentioned before, G.LSP requests issued by a boundary CNE are
    only accepted within the constraints of an O-SLA. This means that
    in case of an untrusted peering relationship, each G.LSP request is
    authenticated and validated against the O-SLA. It was already
    indicated that O-SLAs may also be defined at trusted interfaces.
    However, G.LSP requests received from trusted neighbors don't need
    to be validated against the O-SLA.

    In the scope of this draft, we only discuss the technical aspects
    of an O-SLA. Borrowing from the terminology introduced in
    [diffserv-framework], we refer to the technical part of an O-SLA as
    an Optical Service Level Specification (O-SLS). An O-SLS is
    considered to be unidirectional and to specify performance
    expectations (i.e., the service level) for the IP service domain as
    well as imposed reachability constraints, e.g., CUG.

    O-SLS parameters could for example include:

    1. Capacity constraints

 Duroyon et al.             Expires May 2001                          8

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    An ingress O-SLS may contain limits on the maximum number of G.LSPs
    that can be established from a specific ingress point, possibly as
    a function of time of day, as well as bandwidth constraints (OC-48,
    OC-192, etc.).
    An egress O-SLS may put capacity constraints on the G.LSPs that the
    receiving IP service domain is willing to terminate.

    2. Service performance parameters

    Examples are G.LSP setup and/or recovery admitted latency,
    supported protection/restoration options, availability, supported
    routing constraints, accessibility (i.e., G.LSP request blocking
    probability), responsiveness (specifying upper limits on the
    processing time of G.LSP requests), etc.

    3. Constraints on the 'scope' of G.LSP request

    This may be viewed as an extension to the concept of CUGs, which by
    nature already exhibit reachability limitations. Scope constraints
    are intended to additionally restrict the topological extent of
    G.LSPs. In its simplest form, the O-SLS offers to accept any G.LSP
    request issued by the IP service domain over a specific O-UNI up to
    a maximum capacity without any scope constraint within the CUG (so-
    called hose O-SLS). Conversely, the agreement may be constrained by
    the egress point of a G.LSP. For example, the optical domain
    service provider might agree to the setup of G.LSPs, up to a
    certain maximum capacity, but only if these G.LSPs are destined to
    a specific set of egress points within the CUG.

    Part of the purpose of O-SLSs is to protect resources in the
    optical domain by validation of submitted G.LSP requests. If the
    optical domain and the IP service domain are under control of the
    same administrative authority, then there is likely to be a trusted
    peering relationship between both domains. Conversely, in case of
    an untrusted peering relationship, the optical domain service
    provider validates incoming G.LSP requests as per the O-SLS. This
    validation process can be implemented in the ONE-C. In this case,
    there exist several mechanisms to install an O-SLS in an ONE-C,
    e.g., CLI, SNMP, LDAP or COPS. Alternatively, the O-SLS enforcement
    may be outsourced to another policy entity.

    An O-SLS offers to accept G.LSP requests at the service level
    agreed with the IP service domain. The optical domain service
    provider will provision the optical domain accordingly. A broad
    range of optical services could be envisioned. As an example,
    services could be defined with different levels of accessibility,
    depending on the probability that a G.LSP establishment request is
    blocked. Moreover, services could also be categorized as protected
    or non-protected, depending on the offered protection level. All of
    these service level characteristics influence the resource
    provisioning process in the optical backbone.

 Duroyon et al.             Expires May 2001                          9

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    For each G.LSP request, the optical domain service provider may
    also need to identify the O-SLS for which the request is submitted.
    Some authentication may be included in the request in order to
    verify that the rightful IP service provider issued the request. In
    some cases, this customer might be implicitly derived from the
    signaling channel on which the G.LSP request was received. The
    authentication mechanism must be specified in the O-SLS.

    Although it can be assumed that O-SLSs will be static for the
    foreseeable future, this draft does not preclude dynamic O-SLSs.
    These would necessitate some automated form of interaction between
    the IP service domain and the optical domain. In case of an O-SLS
    at the O-UNI, this may for instance require the interaction between
    a Bandwidth Broker (BB) in the IP service domain and a Lambda
    Broker (LB) in the optical domain. At the level of an O-NNI, this
    would be between different LBs, acting on behalf of the different
    optical sub-networks. This automated (re-)negotiation of O-SLSs
    would in turn call for an automated O-SLS admission control
    function. Note that this admission control function is different
    from the validation of G.LSP requests as per the negotiated O-SLS,
    referred to as O-SLS enforcement.

 8. G.LSP triggers

    As stated in [ip-optical], the G.LSP request triggering process
    should be part of a stable traffic engineering tool in the IP
    service domain as opposed to a data-driven shortcut approach,
    similar to the schemes proposed for IP over ATM networks.
    Henceforth, an integrated TE-LSP and G.LSP triggering process is
    proposed at the end of this section to alleviate the shortcomings
    of the former method and is elaborated below.

 8.1 Data-driven shortcut approach for G.LSPs

    The data-driven shortcut model would imply that the boundary CNEs
    use traffic measurements to autonomously control the number of
    G.LSPs that connect them with a set of remote boundary CNEs across
    the optical domain. For example, boundary CNE A could detect that
    some of its traffic is reaching boundary CNE B in a multi-hop way.
    If this traffic trunk is large enough, boundary CNE A might decide
    to set-up a G.LSP to boundary CNE B, relieving the IP forwarding at
    all intermediate CNEs on the multi-hop path. In an overlay model,
    once a G.LSP has been established to a new destination, it should
    be announced as a (new) IP link in the IP service domain routing
    database. As such, it can be used by any TE entity in the IP
    service domain and this IP link may carry several TE-LSPs. This
    implies that the TE entity in the IP service domain would then be
    constantly reacting to decisions of the boundary CNEs that are
    continuously changing the IP topology.

    Such a layered scheme of G.LSP requests and TE-LSP requests is
    inefficient and could also break the TE service model, when the

 Duroyon et al.             Expires May 2001                         10

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    only available G.LSP between two boundary CNEs would be torn down.
    Such a decision might be based on the valid observation that the
    traffic pattern has changed such that the existing G.LSP is under-
    utilized and may be re-directed towards another boundary CNE.
    However, the G.LSP might still carry TE-LSPs. Turning off the G.LSP
    has the effect of a link failure and will hence trigger the TE
    entity in the IP service domain to recover from this failure.
    Depending on whether the TE-LSP was protected or not, one of the
    following scenarios will take place.

 8.1.1 Protected TE-LSPs

    TE-LSPs can be used to carry mission critical traffic requiring a
    fast recovery scheme in case of link failures. Upon such an event,
    the traffic of the working TE-LSP can be switched to a protect TE-
    LSP that has been pre-configured along a node- and link-disjoint
    path. Depending on whether G.LSP is protected or not throughout the
    optical network, the following alternative is considered:

    - Protected G.LSP: if the turned-off G.LSP was protected within the
    optical domain, the TE-LSP path calculation might have selected
    this IP link for both the working and the protect path of the TE-
    LSP. In that case, the TE-LSP protect path will not be available
    and connectivity will be lost.

    - Unprotected G.LSP: in this case the problem would not arise since
    the route diversity TE-LSP protect scheme would have selected
    another IP link for the protect path.

 8.1.2 Unprotected TE-LSPs

    If the TE-LSP was not protected, the source nodes of the TE-LSPs
    running over the turned-off G.LSP will start a CSPF calculation to
    find an alternative path. As all source nodes will be competing for
    the same resources, some G.LSP requests will be blocked and it
    might take a while before all G.LSPs have been restored.

    The above scenario equally pertains to the case of any link failure
    in an IP service domain. However, link failures in an IP service
    domain may be considered as rare events. This is however not the
    case when this link failure behavior is the result of a data-driven
    shortcut approach across an optical backbone.

 8.2 Integrated TE-LSP and G.LSP triggering process

    Given the above shortcoming, boundary CNEs should not autonomously
    decide to tear down a G.LSP. Yet, it may not always be appropriate
    to maintain an under-utilized G.LSP. However, a G.LSP should not be
    turned off until the TE-LSPs it carries, have been re-routed along
    an alternative path. This might even require an additional G.LSP
    setup between two other boundary CNEs. All of this calls for a
    coordinated TE-LSP and G.LSP triggering process, integrated in the

 Duroyon et al.             Expires May 2001                         11

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    same decision point. This is possible since both responsibilities
    reside within the IP service domain.

    The ability to dynamically establish G.LSPs adds an extra dimension
    to the TE capabilities of an IP service domain. In addition to
    forwarding packets along non-shortest paths, it is now also
    possible to (re-)configure the topology of the IP service domain by
    means of adding, deleting or modifying G.LSPs across the optical
    backbone.

    This integrated decision point will use the set of IP SLAs and the
    derived traffic trunk requirements across the IP service domain
    (possibly complemented with traffic measurements) to determine the
    optimal set of G.LSPs and TE-LSPs.

    Several setup optimization strategies are possible depending on the
    business model in use between the IP Service domain and the optical
    domain, and also the assumptions taken on the pre-existing optical
    topology.

    The TE decision point has the complete knowledge of the IP
    Topology, all optical end-points, including their logical, and
    physical attributes (granularity, protection attributes, _).

    The different strategies may be chosen among the following:

         1- Minimize the number of G.LSPs to be lit up

         This strategy fits in business models where the optical domain
         doesn't belong to the service domain, and as such each
         additional network G.LSP is an additional cost to the service
         domain. The TE decision point optimizes the number of G.LSPs
         to set up through the optical domain for a given IP traffic
         pattern.

         2- Add capacity without rearranging optical topology

         Before triggering new G.LSPs, the TE decision point tries to
         rearrange TE-LSPs without rearranging the underlying optical
         topology.

         3- Add capacity with specific explicit constraints

         Some environment may lead to some specific constraints to be
         taken into account during route computation.

         One simple example is a mixed ATM / IP network. In this
         example TE-LSP used by ATM and their underlying G.LSP must not
         be rearranged during the computation to add optical capacity.
         The TE decision point optimizes the number of G.LSP (and
         subsequently TE-LSP topology) with the possibility of pinning
         down some components (TE-LSP, G.LSP, _)

 Duroyon et al.             Expires May 2001                         12

 draft-duroyon-te-ip-optical-01.txt                       November 2000

         4- Optimize IP topology without any optical constraint

         TE decision point optimizes the IP topology without taking any
         constraint on number of G.LSPs setup. The only constraints
         taken are in this case coming from the end-points attributes.

    In addition to the computation algorithm strategy, the TE decision
    point also takes into account the sort of IP services to be
    achieved, in order to achieve a consistent restoration between
    protocol layers.

    One simple way is to define a linear hierarchy between IP services.

         1.- Layer 1 protection - Non-PSC Level Protection

         This service only applies for IP link built between two PSC-
         capable end-points. The G.LSP connecting both end-points is
         totally protected. It means that it will be chosen from a pool
         of G.LSPs with source and destination drop-side protection
         (1+1, 1:1, Shared Protection). And in addition the G.LSP will
         request a network-protected path via the optical network.

         This service will be mainly seen in a traditional environment
         where the service domain lies on a very reliable transport
         layer, dedicated to any fast restoration mechanism.

         2.- Diverse Layer 2 _ PSC Level Protection

         This service also only applies for a G.LSP built between two
         PSC-capable end-points (for instance, an IP link connection).
         Two G.LSPs are requested to the optical cloud via the same
         CNE-to-ONE interface, using source and destination drop-side
         protected G.LSPs.
         No optical or SDH/Sonet network protection are required for
         the G.LSPs. But diverse optical paths are requested for both
         G.LSPs.

         This service makes sense in a network architecture where the
         CNE is locally connected to an ONE, and so the diverse path
         routing must start at the first ONE of the optical network.

         3. Diverse Layer 2 - Network Level Protection

         This service applies indifferently in a mixed PSC-capable (and
         particularly for IP services) and non-PSC capable optical
         environment, and not necessarily at the boundary CNE.
         Two G.LSPs are requested from the IP service domain using two
         diverse paths. In this case when the G.LSP request reaches the
         optical cloud boundary, there is no specific protection
         requirements towards the optical cloud.

 Duroyon et al.             Expires May 2001                         13

 draft-duroyon-te-ip-optical-01.txt                       November 2000

         4. No G.LSP protection

         This service applies when the restoration mechanisms don't
         rely on pre-existing backup paths. In this case on protection
         constraints have to be taken into account at the optical
         layer.

    As described in this paragraph, in order to create a consistent
    end-to-end IP Service Model, network devices and TE decision point
    have to synchronize each other to setup and maintain the adequate
    and optimal set of G.LSPs and TE-LSPs. The resulting topology is
    based on IP services requirements (Protection scheme, _) and
    computation strategies (Business models, _).

    This leads to needs for potential new standardization items, as
    information exchange between routers and TE decision point (in case
    of G.LSP setup failure, _). This will be tackle via subsequent
    studies.

 9. G.LSP advertisement to the IP layer

    The decision point may thus trigger the set-up of an additional
    G.LSP to an already connected boundary CNE. Alternatively, it may
    trigger a rearrangement of existing G.LSPs, or the establishment of
    a G.LSP to a boundary CNE that could previously not be reached
    through the optical domain. It might very well be that the decision
    point triggers a boundary CNE to drop a G.LSP if its capacity is no
    longer needed to meet the requirements of the IP SLAs.

    In order to make efficient use of the dynamicity of the G.LSP
    create requests, the routing protocol parameters should be
    dynamically configurable as well. This section outlines a proposal
    to achieve a seamless integration of a new G.LSP within the IP
    service domain for the overlay model by means of automatic
    configuration.

    As soon as a G.LSP to a particular boundary CNE has been lit up, it
    is assumed that it is promoted to an operational IP link. In case
    of, e.g., regular SDH/SONET framing, this is achieved by running
    PPP protocol on the newly established G.LSP.

 9.1 G.LSP set-up to a previously unreachable boundary CNE

    The draft [ompls-ospf] defines the different facets of the creation
    of an IP link in case of a peer-to-peer model and proposes to use
    the newly established IP link as a forwarding adjacency in the IP
    service domain.

    The overlay model imposes different requirements on the IP layer of
    the boundary CNEs. Indeed, once the first G.LSP is established
    between two boundary CNEs and promoted as IP link, it is to be
    advertised as a point-to-point link for IP routing in order to

 Duroyon et al.             Expires May 2001                         14

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    initiate the IP connectivity between the two boundary CNEs. And
    subsequently it will allow IP reachability between the associated
    IP service domains.

    Two cases must be considered. The G.LSP is promoted to an IP link
    connecting:

    - two boundary CNEs of the same Autonomous System (IGP peering),
    or,

    - two boundary CNEs of different Autonomous Systems (eBGP peering).

    The IGP and BGP peering cases do not require the same kind of
    configuration and are described separately.

    Note that in case of an IGP peer, it is necessary that the G.LSP be
    bi-directional, because IGP protocols require a bi-directional
    transport layer. Bi-directional G.LSP setup is further detailed
    within [g-mpls] and [onni-framework].

    From an addressing point of view, the Packet switch capable end-
    points can be unnumbered (and, e.g., identified by the Router Id of
    the boundary CNE), or numbered through initial configuration, but
    different from the IP address assigned to the UNI signaling agents
    (UNI-Client and UNI-Network) terminating the signaling channel.

    It has to be noticed again that within the overlay model, the
    signaling channel identification is neither known nor advertised
    throughout the IP service domain.

 9.1.1 IGP support

    Once the first IP link is established between two boundary CNEs and
    configured to support an IGP peer, the boundary CNEs need to get
    the proper information:

    - The first requirement is to select IS-IS or OSPF for the newly
    formed IP link.

    - In addition, link routing parameters such as timers and area
    numbers might have to be specified. For instance, timers in OSPF
    should be consistent at both ends of the IP link.

    - Also, link metrics (e.g., resource classes, etc.) need to be
    inherited or configured for use by IP routing.

    - Finally, the IGP protocol is enabled and the IP link is
    advertised.

    These parameters have to be accessible and are automatically
    configured (prior to or at the time of G.LSP establishment) by the

 Duroyon et al.             Expires May 2001                         15

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    decision point of the IP service domain to efficiently deploy the
    IP service on top of the G.LSP.

    However, some of the routing parameters (e.g., OSPF timers) may be
    defaulted to pre-determined values. Those values must be defined
    network-wide and be consistent between all possible boundary CNE
    pairs. The decision point should be allowed to overwrite those
    parameters at the setup time of the G.LSP.

 9.1.2 eBGP peering

    In the case of an inter-domain G.LSP, static route configuration
    specifying the BGP peer (most probably a virtual interface of the
    remote boundary CNE) should be configured in the local boundary CNE
    in order to set up the TCP session used in BGP.

    In addition, an IP SLA is going to be negotiated between the
    autonomous systems and routing policies are going to be configured
    on both ends of the G.LSPs.

    As opposed to the IGP peering case, triggering of inter-domain
    G.LSPs will very likely not arise from an automated process because
    of the BGP peering negotiation procedure.

 9.2 Set-up of an additional G.LSP

    In addition to the option described in 9.1 (creation of a new
    stand-alone IP link with the new G.LSP and advertisement to the
    routing protocol), a second option is now possible, which is to
    create an additional G.LSP to an existing IP link that forms a
    bundled link [mpls-bundle]. In this case there is no new
    configuration necessary for the IGP or BGP routing layer but only
    interactions internal to the boundary CNEs.

    This bundle is advertised as a single IP link. The G.LSP in itself
    may be unidirectional, and hence the bundle could have an
    asymmetric bandwidth.

    - The boundary CNE upgrades the bandwidth of the bundle link based
    on the characteristics of this new G.LSP.

    - The new G.LSP is included in the load balancing mechanism that
    distributes the traffic amongst the component G.LSPs of the bundled
    link, e.g., proportional to their bandwidth.

    - The addition of a new G.LSP to a bundle does not impact the
    routing topology. Only the new bandwidth of the IP link is
    advertised within the IP service domain. The other characteristics
    of the IP link, e.g., the resource classes, remain unchanged.

 Duroyon et al.             Expires May 2001                         16

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    In the case described in this section, the only mandatory
    information to be automatically configured by the decision point is
    the bundle identifier to which the G.LSP is to be added.

 9.3 Rearrangement of an existing G.LSP

    Within the optical network, two alternatives could be considered
    for the rearrangement of an existing G.LSP:
    - Either the non-destructive modification of an already established
    G.LSP. In this case, the source and destination termination-points
    of the G.LSP can not be changed, but other parameters such as
    bandwidth and network protection could be modified without
    disrupting the working G.LSP.
    - Or the destructive modification of an already established G.LSP.
    This case is the straightforward combination of G.LSP tear-down
    followed by a new G.LSP set-up towards a different destination.

 10. References

    [diffserv-framework] Y.Bernet et al, "A Framework for
    Differentiated Services", Internet Draft, draft-ietf-diffserv-
    framework-03.txt, February 1999.

    [g-mpls] Peter Ashwood-Smith et al., "Generalized MPLS _ Signaling
    Functional Description", Internet draft, draft-ietf-mpls-
    generalized-signaling-00.txt, October 2000.

    [ip-optical] James Luciani et al., " IP over Optical Networks _ A
    Framework", Internet draft, draft-ip-optical-framework-00.txt,
    February 2000.

    [ompls-isis] K. Kompella et al., "IS-IS Extensions in Support of
    MPL(ambda)S", Internet Draft, draft-kompella-isis-ompls-extensions-
    00.txt, July 2000.

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

    [mpls-bundle] K. Kompella et al., "Link Bundling in MPLS Traffic
    Engineering", Internet Draft, draft-kompella-mpls-bundle-02.txt,
    July 2000.

    [onni-framework] D.Papadimitriou et al,. "Optical NNI Framework and
    Signaling Requirements", Work in progress, draft-papadimitriou-
    onni-framework-00.txt, November 2000.

    [ouni-framework] B.Rajagopalan et al., `Signaling Requirements at
    the Optical UNI', Internet Draft, draft-bala-mpls-optical-uni-
    signaling-00.txt, July 2000.

 Duroyon et al.             Expires May 2001                         17

 draft-duroyon-te-ip-optical-01.txt                       November 2000

    [OIF2000.125.2] B. Rajagopalan et al., "User Network Interface
    v1.0 Proposal", OIF Contribution 125.2, October 2000.

    [OIF2000.200] D. Pendarakis et al., "Signaling Transport
    Mechanisms for UNI 1.0", OIF Contribution 200, September 2000.

    [OIF2000.261.1] D. Papadimitriou et al., "Address Registration and
    Resolution", OIF Contribution 261, November 2000.

 11. Acknowledgments

    The authors would like to thank Emmanuel Desmet, Sitaram
    Kalipatnapu and Gert Grammel for their constructive comments.

 12. Author's Addresses

    Olivier Duroyon
    Alcatel USA
    15036 Conference Center Drive
    Chantilly, VA, 20151
    Phone: (703) 679 6415
    Email: [email-masked]

    Rudy Hoebeke
    Alcatel Bell
    Francis Wellesplein 1
    2018 Antwerp, Belgium
    Phone: (32) 3/240.84.39
    Email: [email-masked]

    Hans De Neve
    Alcatel Bell
    Francis Wellesplein 1
    2018 Antwerp, Belgium
    Phone: (32) 3/240.76.94
    Email: [email-masked]

    Dimitri Papadimitriou
    Alcatel NSG-NA
    Francis Wellesplein 1
    2018 Antwerp, Belgium
    Phone: (32) 3/240.84.91
    Email: [email-masked]

 Duroyon et al.             Expires May 2001                         18