Internet DRAFT - draft-aboulmagd-srvc-def-crldp
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
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
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
protocol.
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
association.
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
weight
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
requirement.
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
necessary.
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
scheduler.
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
dropped.
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
figure.
+---------------+ +-----+ +--------------+
| | | | | |
| 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
characteristics.
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
CDVT
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
CDVT
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
dropped.
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
requirements).
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-
conformant
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
1998
[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
draft.
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
Canada
Phone: +1 613 763-5829
Email: osama@nortelnetworks.com
Bilel Jamoussi
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
USA
Phone: +1 978 288-4506
Email: jamoussi@nortelnetworks.com
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
