Internet DRAFT - draft-aboulmagd-srvc-def-crldp


     MPLS Working Group                                        O. Aboul-Magd
                                                                 B. Jamoussi

     Internet Draft                                          Nortel Networks
     Document: draft-aboulmagd-srvc-def-crldp-00.txt            October 1999
     Category: Informational

          A Framework for Service Definition and Interworking Using CR-LDP

     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

        The list of Internet-Draft Shadow Directories can be accessed at

     1. Abstract

     Label-distribution protocol (LDP) is defined in [1] for the distribution
     of labels inside one MPLS domain. CR-LDP is defined in [2] to work in
     conjunction with the LDP for establishing label switched paths with
     prescribed QoS requirements. The establishment of those paths is called
     constraint-based routing (CR) and it offers the opportunity to extend the
     information used to setup paths beyond what is available for the routing

     To facilitate the establishment of CR paths, the CR-LDP specification
     include the essential entries (TLVs) to allow the characterization of the
     traffic requirements and service expectations. The objectives of this
     draft are to establish a general framework for service definition using
     the mechanisms specified in [2] and to illustrate how service interworking
     could be achieved between an MPLS domain using CR-LDP and other domains
     that might employ similar or different networking technologies.

     2. Introduction

     Aboul-Magd               Expires April, 2000                         1

                     A Framework for Srvc Def using CR-LDP    October, 1999

        In an MPLS domain [3], when a stream of data traverses a common path, a
        label switching path (LSP) can be established using LDP signaling
        protocol. To facilitate the assignment of QoS properties to an LSP the
        LDP methods and procedures are extended in CR-LDP to allow for this

        With the introduction of the QoS capabilities, planning for new
        services, other than the traditional best effort service, is now
        possible. While CR-LDP allows for signaling a number of QoS-related
        parameters, it does not specify or explicitly provide for the signaling
        of pre-defined services. This approach, of not explicitly defining or
        signaling services, is a departure from other QoS architectures such as
        the ATM service categories defined in [4].

        The CR-LDP approach for service definition borrows from, and is
        consistent with, that suggested for the differentiated services
        (Diffserv) architecture [5]. The salient feature of that approach is
        the separation between the edge rules, implemented at the edge LSR, and
        the local behavior, implemented at the various nodes of the networks.
        The adaptation of this approach achieves two main objectives:

        - A network operator has the flexibility to define those services that
        fit his business.

        - Services are not `hardwired' by correlating the edge rules to the
        local behavior (e.g. the GS [6] and the CLS [7] in Intserv model).

        With this recognized flexibility, interworking between different MPLS
        domains employing different services becomes essential. Of equal
        importance is the interworking between MPLS/CR-LDP QoS architectures
        and those of other QoS architectures such as ATM, Intserv, FR, etc.

     3. Overview of CR-LDP QoS Capabilities

        The traffic parameters TLV of the CR-LDP is shown below

           0                   1                   2                   3
           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
           |0|0| Traf. Param. TLV  (0x0810)|      Length                   |
           |     Flags     |    Frequency  |     Reserved  |    Weight     |
           |                    Peak Data Rate (PDR)                       |
           |                    Peak Burst Size (PBS)                      |
           |                    Committed Data Rate (CDR)                  |
           |                    Committed Burst Size (CBS)                 |

     Aboul-Magd               Expires April, 2000                         2

                     A Framework for Srvc Def using CR-LDP    October, 1999

           |                    Excess Burst Size (EBS)                    |

        In a nutshell the traffic parameters TLV allows for:

        - The signaling of parameters relevant to traffic characteristics
        - Indication of the required service frequency
        - The assignment of different weights to different LSPs, and
        - The ability to renegotiate each of the traffic parameters and the LSP

        TLV parameters that are relevant to traffic characteristics are peak
        date rate (PDR) and committed data rate (CDR). Both PDR and CDR are
        measured over specified time intervals as defined by the peak burst
        size (PBS) and the committed burst size (CBS). In addition to CBS, an
        LSP could burst at its CDR up to a level specified by an excess burst
        size (EBS).

        From the user perspective, those traffic related parameters are useful
        in signaling to the MPLS domain of the user desired parameters, e.g. a
        certain CDR. To the network those parameters are used to execute the
        local admission control function at each of the LSR along the path.

        If specified by the user, a simple token bucket algorithm could monitor
        each of PDR and CDR. For instance for the PDR could be monitored by a
        token bucket with, token rate = PDR and maximum token size = PBS. For
        the CDR, and if EBS is specified, two token buckets, C and E, are
        proposed. The C and E token buckets are incremented at the CDR. The C
        bucket, when full, overflows into the E.

        The specification of the service frequency is an indication to the
        network of the delay characteristics that are required from the
        network. For services with stringent delay requirements that are not
        able to tolerate large delay variations, a VeryFrequent granularity of
        the CDR is to be used. This implies that the rate assigned to the
        service should average at least its CDR when measured over any time
        interval equal to or longer than the shortest packet time at CDR. This
        assignment ensures that the transmission resources, as governed by the
        packet scheduler, are available to a particular LSP at a rate that is
        at least equal to its data arriving rate, assuming the shortest
        possible packet size. Hence data are expected to be served as they
        arrive and accumulation of delay greater than L/CDR is not permitted
        where L is the shortest packet size.

        For applications [8] that can tolerate some amount of delay variations,
        the service frequency can be assigned the value Frequent. This implies
        that the available rate should average at least the CDR measured over
        any time interval equal to or longer than a small number of shortest
        packet times at CDR. Hence packets are served after a delay that is
        bounded by a few packet times measured at CDR. The number of packets is

     Aboul-Magd               Expires April, 2000                         3

                     A Framework for Srvc Def using CR-LDP    October, 1999

        a configurable parameter that is set to meet the service delay

        Other services such as elastic service [8] can be assigned the value
        Unspecified. This implies that the CDR may be provided at any
        granularity. Thus CDR might be guaranteed over a longer time scale than
        that offered by VeryFrequent or Frequent assignments.

        CR-LDP allows for resource sharing among a number of CR-LSPs sharing
        the same interface. The Weight parameter determines the CR-LSP relative
        priority when assigning excess nodal bandwidth or under congestion
        conditions. The implementation of a particular fairness criterion is
        MPLS domain specific.

        Negotiation allows the network to offer a CR-LSP a set of revised
        parameters and Weight that are more suitable for the current network
        state. Parameter negotiation is allowed only if indicated by the
        appropriate Flag. Flags are provided for PDR, PBS, CDR, CBS, EBS, and
        Weight. Negotiation is only allowed in that direction where the
        parameter values are lowered from those defined in the original
        signaling message. If modified, the node MUST overwrite the modified
        parameters before forwarding the message to the next node. A node might
        elect to change its reservation level based on the new parameter values
        carried in the traffic parameters TLV in the label mapping message.

        While not the concern of this draft, procedures for user-initiation re-
        negotiation of the CR-LSP parameters are outlined in [9]. This
        capability, if implemented, is useful to introduce changes to the
        reservation level of an LSP as a function of the actual usage.

     4. Service Definition Framework

     4.1 Service Model

        A CR-LDP service model could have supported three categories of
        applications that are classified by their delay requirements [8]. The
        most demanding group of applications are those that cannot tolerate
        delay or loss such as circuit emulation services or intolerant real
        time applications. The second categories of applications are
        applications that can tolerate some loss or delay.  Examples of these
        applications are tolerant real time systems or real time data
        applications that require reasonably quick response to function. The
        support of those applications requires the definition of real time
        service (RTS) to meet the delay objective of the applications.

        Elastic applications are those that are traditionally handled using
        best effort service. One important nature of elastic applications is
        the absence of a packet due time and each received packet is used
        immediately without the need to buffer for some later time [8]. Those
        applications rely on the sustained flow of packets, no matter how long

     Aboul-Magd               Expires April, 2000                         4

                     A Framework for Srvc Def using CR-LDP    October, 1999

        they are delayed (as long as the delay is not excessive), and could be
        considered as throughput sensitive (TS) applications.

        In that respect a CR-LDP domain is expected be able to support a
        minimum of two broad classes of services, RTS and TS service, in
        addition to the traditional best effort service.

        As mentioned before, the CR-LDP service model goes beyond that of
        specifying particular services. The CR-LDP model provides a set of
        building blocks that allows the construction and the definition of many
        services. This model is fundamentally sound, as it does not require
        changes to the basic paradigm every time the need for a new service
        arises. This model is also flexible, as it does not mandate the use of
        particular services for which operational experience might show that
        they are useless or inadequate. This model also facilitates the service
        interworking between different domain employing different networking
        technologies, as it will be discussed later.

        The main building blocks for QoS-based services support using CR-LDP is
        the definition of edge rules to be implemented at the edge LSR and the
        definition of local behaviors in terms of resource allocation and
        packet forwarding.

        Edge rules are specifically defined as not signaled in the CR-LDP. Edge
        rules are left as part of the contract between network providers and
        customers and are configured using node management system. Those rules
        might include policing with some specified policing actions in terms of
        packet drop or marking for discard eligibility.

        CR-LDP signals parameters that are sufficient to characterize the local
        behavior in terms of packet forwarding. Traffic parameters such as PDR,
        PBS, etc. are useful in deciding the allocation level for a particular
        CR-LSP. Frequency and Weight are useful indication to show how often
        packets of a given CR-LSP must be serviced and how to share resources
        among a number of competing CR-LSPs. This approach is similar to the
        PHB concept in the Diffserv architecture [5].

     4.2. Nodal Mechanisms

        There are minimum requirements that must be satisfied before a network
        becomes QoS-enabled [8]. One of those requirements is the availability
        of an adequately defined signaling mechanism. In the context of this
        draft this requirement is fulfilled by CR-LDP. Other requirements
        include admission control and packet dropping and scheduling as shown
        in the figure. Admission control and packet scheduling are local issues
        pertaining to the nodal architecture.

                     |                       |
                     |                       |
             CR_LDP  |       +-------+       |

     Aboul-Magd               Expires April, 2000                         5

                     A Framework for Srvc Def using CR-LDP    October, 1999

             ===============>|Admis  |=============>
                     |       |Control|       |
                     |       +-------+       |
                     |                       |
                     | +--+     +--+  +--+   |
             =======>  |  |---->|  |->|  |=========> Data Path
                     | +--+     +--+  +--+   |
                     | TC    buffer  scheduling
                     |       mgmt            |

        The admission control module acts on the traffic parameters TLV. Based
        on the supplied parameters values the module computes the amount of
        resources needed to be reserved. If those resources could be supplied
        given the current nodal state, then the admission control module
        forwards the signaling message to its peer in the next hop. If no
        sufficient resources exist, then the admission control function sends a
        notification message indicating that resources are not available.

        The controlled dropping of packets is important for some services. The
        MPLS packet header does not explicitly provide for a drop precedence
        field. It has been proposed [10] that the Exp field in the MPLS header
        is used for indicating the drop precedence for each packet. The Exp
        field can also be used for differently scheduling packets that belong
        to the same CR-LSP.

     4.3. Service Definition Model and Examples

        Service definition in an MPLS domain using CR-LDP follows the same
        paradigm as in the Diffserv architecture [5]. The service definition
        task is carried out by identifying the rules enforced at the network
        edges and the local behavior expected at the LSR. Service definition is
        often referred to as [11-12]:

        Services = Rules + Behavior

        Edge rules are equivalent to traffic conditioning in the Diffserv
        architecture. Edge rules include those functions related to metering,
        policing, shaping, etc. Edge rules also define actions of the edge LSR
        regarding CR-LSP packets that are deemed non-conformant to its traffic
        contract. Those actions could include drop, forward, forward with a
        maximum limit, etc.

        The edge rules are not explicitly specified or signaled in CR-LDP. It
        is expected that those rules will be part of the traffic contract
        between the customer and the operator. This part of the contract
        defines the traffic conditioning function and its action and it could
        be modified only by mutual agreement of the parties involved. The
        actual parameters used for traffic conditioning could be extracted from
        the CR-LDP signaling message or could be permanently configured.

     Aboul-Magd               Expires April, 2000                         6

                     A Framework for Srvc Def using CR-LDP    October, 1999

        The discussion about the edge rules should not imply that traffic
        conditioning is only recommended at the edge of the network. Traffic
        conditioning functions such as shaping and policing could also be
        implemented anywhere in the network the network provider deemed

        The local behavior is determined by the traffic parameters in the
        signaling message. Those traffic parameters define how packets
        belonging to a CR-LSP will be treated. For instance, packets of a CR-
        LSP requesting a VeryFrequent frequency of service will be directed the
        appropriate queue, e.g. the highest emission priority queue in an link

        The service definition paradigm described here can be used to describe
        two RTS and TS services introduced in section 4.1. For RTS service with
        CBR-like traffic the traffic parameters TLV entries could be set at:

        PDR:         service rate (e.g. coding rate in voice applications)
        PBS:         few packets to account for the multiplexing effect
        CDR:         PDR
        CBS:         PBS
        EBS:         0
        Service Frequency:   VeryFrequent or Frequent depends on the tolerance
        level of the application
        Edge rules:  token bucket policing with parameters (PDR, PBS)
                             Drop non-conformant packets

        The dropping of non-conformant packets is included in the edge rules to
        avoid the region of the queue operation where a small increase in the
        load leads to large delay. Allowing non-conformant packets with
        potentially uncontrolled load could lead to a situation where the delay
        objectives of the service are not satisfied.

        For the TS service, the traffic parameters TLV entries could be set at:

        PDR: Service rate (could be set at the access rate)
        PBS: few packets to account for the multiplexing effect (note that PBS
        = 1 if PDR = access rate)
        CDR: Committed rate (e.g. n*64 Kbps)
        CBS: maximum expected burst (e.g. some multiple of the maximum protocol
        data unit)
        EBS: 0
        Service Frequency:   Unspecified
        Edge rules:  Two token buckets policing with parameters (PDR, PBS) and
                     (CDR, CBS)
                     Packets non-conformant to (CDR, CBS) token bucket are
                     marked for high discard precedence using the Exp filed.
                     Packets non-conformant to (PDR, PBS) token bucket are

     Aboul-Magd               Expires April, 2000                         7

                     A Framework for Srvc Def using CR-LDP    October, 1999

     4.4 LSP Merging

        LSP merging is an important MPLS feature that is necessary for the
        support of scalable networks. The service definition model described
        here allows LSP merging as long as LSPs of the same service and QoS
        parameters are merged together. In that respect the service definition
        paradigm described here is equivalent to overlaying a service layer on
        top of the MPLS region. The minimum requirement is to have a single LSP
        provisioned for each service supported.

     5. Interworking Model

        Networking is not a homogeneous environment. Packets traverse multiple
        domains (under the same or different administration authorities) with
        different networking technologies. Interworking between the QoS
        architecture of various technologies is needed to ensure the
        homogeneity of the end-to-end services. With the service definition
        paradigm adapted for the CR-LDP, mapping between different MPLS domains
        becomes essential because different MPLS domains might support
        different services.

        A general architecture for service inter-working is shown in the

             +---------------+  +-----+  +--------------+
             |               |  |     |  |              |
             |  Domain 1     |--+IWU  +--|   Domain 2   |
             |               |  |     |  |              |
             +---------------+  +-----+  +--------------+

        The Interworking unit (IWU) is responsible for service and/or packet
        mapping from one domain to the other. Therefore the IWU must be aware
        of the services offered on its interfaces and be capable of performing
        the appropriate parameter transformation. The IWU should also initiate
        the appropriate signaling procedure, if required, to establish a
        session with adequate service in the corresponding domain.

        At the IWU, the incoming packets on a certain interface are classified
        according to the services they belong to. Packets are then mapped to
        the appropriate services supported by the other domain. The selected
        mapping is pre-configured at the IWU. Needless to say that mapping
        between services MUST be performed between services of the same

     5.1 Interworking Between Different MPLS/CR-LDP domains

        The interworking between two MPLS domains using CR-LDP is a straight
        forward. The service definition methodology described in the last
        section could be used to construct similar services at the two domains.

     Aboul-Magd               Expires April, 2000                         8

                     A Framework for Srvc Def using CR-LDP    October, 1999

        Service and parameter mapping from one domain to the other is done on a
        one-to-one basis.

     5.2 CR-LDP Interworking with Diffserv

        As it has been mentioned before, CR-LDP employs a compatible service
        definition paradigm to that of Diffserv. There are two possible ways
        for interworking. The first one is to overlay the Diffserv PHB model on
        top of MPLS. In that case extensions to LDP [10] are needed to signal
        the desired PHB to be offered by the MPLS domain. Those extensions are
        discussed in more details in [13].

        The advantage of this interworking model is it allows the network
        operator to carry the Diffserv traffic transparently through the MPLS
        region irrespective of the service they belong to in the Diffserv
        domain. It also allows the network operator to service qualitative QoS
        applications (applications that are not able to are not able quantify
        their traffic and QoS requirements) [14] using Diffserv CoS.

        The disadvantage of this approach is that different Diffserv domains
        might use the same PHB coding for constructing of different services
        with different objectives. Carrying those packets transparently in the
        MPLS region could result in service degradation.

        The second method of interworking is to overlay a service layer on top
        of the MPLS region and it relies on mapping services between the
        Diffserv and the CR-LDP domains. This method is a service aware model
        that preserves the integrity of the end-to-end service as long as
        services with the same characteristics are mapped from one domain to
        the other.

     5.3 CR-LDP Interworking with ATM Service Categories

        The ATM QoS architecture offers a number of end-to-end services with
        defined traffic and QoS parameters. Each ATM service category is
        defined by a conformance definition [4] that is equivalent to the edge
        rules discussed earlier. The local behavior is not explicitly defined
        but is implied by the performance objectives of the service categories.
        For instance, the CBR service category imposes the most delay stringent
        requirement and it cells are handled in the node accordingly.

        The conformance definition specifies the relevant traffic parameters
        and to what streams they are applied. It also specifies the policing
        options at the edge, e.g. tagging or dropping. By varying the
        conformance definition at the edge variant subclasses of the same
        service category are possible, e.g. VBR.1, VBR.2, and VBR.3.

        Using CR-LDP, the ATM service categories can be constructed by matching
        the edge rules in MPLS region to the conformance definition in ATM. The
        examples below show how to construct the CBR and the VBR.3 services
        using CR-LDP.

     Aboul-Magd               Expires April, 2000                         9

                     A Framework for Srvc Def using CR-LDP    October, 1999

        CBR Service

        PDR: PCR
        PBS: = |_ 1 + -----------_| Where T=1/PCR and d = 1/link_rate
                       T _ d
        CDR:         PDR
        CBS: 0
        EBS: 0
        Service Frequency:   VeryFrequent
        Edge rules:  token bucket policing with parameters (PDR, PBS)
                     Drop non-conformant packets

        VBR.3 Service

        PDR: PCR
        PBS: = |_ 1+ -----------_| Where T=1/PCR and d = 1/link_rate
                       T _ d
        CDR: SCR
        CBS: MBS
        EBS: 0
        Service Frequency:   Frequent or Unspecified
        Edge rules:  token bucket policing with parameters (PDR, PBS)
                     Drop non-conformant packets
                     Token bucket policing with parameters (CDR, CBS)
        Non-conformant packets are marked for high discard precedence

        The choice of the service frequency depends on the whether the VBR.3
        service is real-time or non real-time.

     5.4 MPLS Interworking with Frame Relay (FR) Service

        FR defines up to four classes of service that covers real-time and non-
        real-time services. The default service class is the one that provides
        rate assurances without delay requirements.

        AT the user-network interface the services is defined by the a set of
        parameters that include CIR, EIR, Bc and Be. The mapping of the default
        FR service to MPLS/CR-LDP can be achieved as:

        PDR: EIR (could be set at the access rate)
        PBS: few packets to account for the multiplexing effect (note that PBS
             = 1 if PDR = access rate)
        CDR: CIR
        CBS: Bc

     Aboul-Magd               Expires April, 2000                        10

                     A Framework for Srvc Def using CR-LDP    October, 1999

        EBS: Be
        Service Frequency:   Unspecified
        Edge rules:  Two token buckets policing with parameters (EIR, PBS) and
                     (CIR, Bc+Be)
                     Packets non-conformant to CIR, CBS, but within Be, token
                     bucket are marked for high discard precedence using the
                     Exp filed.
                     Packets non-conformant to (EIR, PBS) token bucket are

        While an Unspecified service frequency is adequate for the default FR
        service, VeryFrequent or Frequent are also possible for the support of
        real-time applications such as VoFR.

     5.5 MPLS Interworking with Integrated Service

        The integrated service model supports two services, GS [6] and CLS [7].
        The QoS objective of the GS is provide a strict upper bound on the end-
        to-end delay. The CLS service ensures a level of performance that is
        equivalent to a non-congested IP network (no specific delay

        Both the GS and The CLS services are defined in terms of token bucket
        parameters (r, b), peak rate (p), minimum policed unit (m), and a
        maximum policed unit (M). However their policing functions are
        different. For GS service, the amount of data sent over any time
        interval should not exceed M+min[pT, rT+b-M]. For CLS, the amount of
        data should not exceed rT+b independent of p. Data that exceeds the
        specified amount could be marked as non-conformant.

        The interworking between MPLS/CR-LDP and integrated service can be
        achieved as:

        GS Service

        PDR: p
        PBS: M
        CDR: r
        CBS: b
        EBS: 0
        Service Frequency:   VeryFrequent or Frequent
        Edge rules:  p and r policing
                     Traffic in excess of M+min[pT, rT+b-M] are dropped or 
             or marked for discard

        The specification of the service frequency as either VeryFrequent or
        Frequent depends on the stringent of the delay bound.

        CLS Service

     Aboul-Magd               Expires April, 2000                        11

                     A Framework for Srvc Def using CR-LDP    October, 1999


        PDR: p
        PBS: M
        CDR: r
        CBS: b
        EBS: 0
        Service Frequency:   Frequent
        Edge rules:  (r,b) policing with marking option
                     Traffic in excess of rT+b should be marked as non-

     6. Security Considerations

        This document does not introduce any new security issues

     7. References

     Aboul-Magd               Expires April, 2000                        12

   [1]  Andersson et. al., _Label Distribution Protocol Specification_
   work in progress (draft-ietf-mpls-ldp-05), June 1999

   [2]  Jamoussi, _Constraint-Based LSP Setup using LDP_ work in
   progress (draft-ietf-mpls-cr-ldp-03.txt), Sept. 1999

   [3]  Rosen, et. al., _Multiprotocol Label Switching Architecture_
   work in progress (draft-ietf-mpls-arch-06.txt), August 1999

   [4]  ATM Forum, _Traffic Management Specification: Version 4.1_,
   March 1999

   [5]  S. Blake, _An Architecture for Differentiated Service_ RFC
   2475, December 1999

   [6]  S. Shenker, et. al., _Specification of Guaranteed Quality of
   Service_ RFC 2212, Sept. 1997

   [7]  J. Wroclawski, _Specification of the Controlled-Load Network
   Element Service_ RFC 2211, Sept. 1997

   [8]  R. Braden, et. al, _Integrated Services in the Internet
   Architecture: an Overview_, RFC 1633, July 1994

   [9]  J. Ash, et. al., _LSP Modification using CR-LDP_, work in
   progress (draft-ash-crlsp-modify-00.txt), July 1999

   [10] J. Heinanen, _Differentiated Services in MPLS Networks_, work
   in progress (draft-heinanen-diffserv-mpls-00,txt), June 1999

   [11] J. Wroclawski, _Applications, Flexibility, and Differentiated
   Services_, Internet 2 Joint Application/Engineering Workshop, May

   [12] V. Jacobson, _Differentiated Services for the Internet_,
   Internet 2 Joint Application/Engineering Workshop, May 1998

   [13] Faucheur, et. al., _MPLS Support of Differentiated Service_
   work in progress (draft-ietf-mpls-diff-ext-02.txt), October 1999

   [14] Y. Bennet, et. al., _Framework for Integrated Services
   Operation over Diffserv Networks_, work in progress (draft-ietf-
   issll-diffserv-rsvp-03.txt), September 1999.

8. Acknowledgement

   The authors would like to thank Don Fedyk for his comments on the

9. Author's Addresses
                A Framework for Srvc Def using CR-LDP    October, 1999

   Osama Aboul-Magd
   Nortel Networks
   P.O. Box 3511, Station _C_
   Ottawa, Ontario, K1Y-4H7
   Phone: +1 613 763-5829

   Bilel Jamoussi
   Nortel Networks
   600 Technology Park Drive
   Billerica, MA 01821
   Phone: +1 978 288-4506
                A Framework for Srvc Def using CR-LDP    October, 1999

Full Copyright Statement

   "Copyright (C) The Internet Society (1999). 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
                A Framework for Srvc Def using CR-LDP    October, 1999