Internet-Draft                                               P. Vaananen
Expiration Date: September, 1998                Nokia Telecommunications

                                                            R. Ravikanth
                                                   Nokia Research Center

                                                             March, 1998
 

          Framework for Traffic Management in MPLS Networks

              <draft-vaananen-mpls-tm-framework-00.txt>



STATUS OF THIS MEMO 

This document is an Internet-Draft. 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".

To learn the current status of any Internet-Draft, please check the 
"lid-abstracts.txt" listing contained in the Internet-Drafts Shadow 
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 
ftp.isi.edu (US West Coast).
 
ABSTRACT

It has been recognised that the success of the MPLS depends on the 
ability to better support the multiservice traffic integration with 
some levels of service guarantees, which are not feasible to implement 
with the current destination prefix only based packet forwarding 
paradigms.

The efficient support for these services throughout the network is 
expected to be possible using label based forwarding paradigm in the 
network.

However, the service categories and the enabling mechanisms to support 
those service categories are not well addressed in the current 
proposals for the MPLS working group; the effort has mostly 
concentrated on the handling of the best effort traffic and associated 
scalability and routing related issues.

The goal of this document is to define a framework for traffic 
management in MPLS networks. We discuss the set of mechanisms that have 
been proposed for enabling the implementation of the more advanced 



P.Vaananen, R. Ravikanth                                        [Page 1]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


services than pure best-effort packet forwarding, and the impact of 
those mechanisms with respect to MPLS network environments and MPLS 
protocol implementation.

The document describes the mechanisms and their application with the 
intent to approach the level of the traffic management capabilities 
that are currently available in hybrid router/ATM or frame relay 
networks using the MPLS. The approach taken is that no modifications 
are required in the end station protocol or application software in the 
first phase of deployment, while this might be allowed later, if deemed 
necessary.

This document concentrates on the issues from the public network 
operators point of view, although most of the discussion applies as 
well in the local network environments.

Concepts and mechanisms described in this document are based on the 
previous work done in the subject on various working groups of IETF and 
other standardisation bodies. It has been attempted to use applicable 
concepts and terminology from previous work as much as possible. 

This document concentrates on the MPLS specific issues, number of 
related mechanisms and concepts are only briefly presented for sake of 
completeness, and the other related work is referred, where applicable. 
Reader is suggested to consult the referred material, in case he / she 
wants to have more information on these areas.
 
ACKNOWLEDGEMENTS

The ideas presented in this in document have been based on the 
information collected from a number of sources. 
--- Individuals to be added ---


1. TABLE OF CONTENTS
STATUS OF THIS MEMO
ABSTRACT...............................................................1
ACKNOWLEDGEMENTS.......................................................2
1.      TABLE OF CONTENTS..............................................2
2.      INTRODUCTION...................................................5
3.      SERVICE CATEGORIES.............................................5
3.1     BEST EFFORT SERVICES..........................................,6
3.1.1   Enhanced best effort service...................................6
3.1.2   Enhanced best effort service with bandwidth allocation.........6
3.1.3   Enhanced best effort services in MPLS environments.............6
3.2     DIFFERENTIATED SERVICES........................................7
3.2.1   Differentiated service.........................................7
3.2.2   Differentiated services with bandwidth allocations.............8
3.2.3   Differentiated services in MPLS environments...................8
3.3     GUARANTEED SERVICES............................................8



P.Vaananen, R. Ravikanth                                        [Page 2]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


3.3.1   Services.......................................................9
3.3.2   Guaranteed services in MPLS environments.......................9
4.      TRAFFIC MANAGEMENT REQUIREMENTS...............................10
4.1     SERVICE CATEGORY SUPPORT......................................10
4.2     ADMISSION CONTROL, MONITORING AND SECURITY....................11
4.3     CONGESTION MANAGEMENT.........................................11
4.4     SCALABILITY REQUIREMENTS......................................11
4.5     ROBUSTNESS AND RELIABILITY....................................12
4.6     TOPOLOGY SUPPORT..............................................13
4.7     TOPOLOGICAL SCOPE.............................................13
4.8     COMPATIBILITY.................................................14
4.9     EXTENSIBILITY.................................................14
5.      CONTROL PLANE MECHANISMS FOR TRAFFIC MANAGEMENT FUNCTIONS.....15
5.1     TRIGGERS......................................................15
5.1.1   Configuration events..........................................16
5.1.2   Signaling events..............................................16
5.1.3   Topology changes..............................................16
5.1.4   Traffic pattern changes.......................................16
5.2     POLICY AND ADMISSION CONTROL..................................17
5.2.1   Routing policy................................................17
5.2.2   Classification policy.........................................17
5.2.3   Admission policy..............................................18
5.2.4   Admission control.............................................18
5.3     PATH SELECTION................................................19
5.4     ACCOUNTING....................................................19
5.5     USER AUTHENTICATION...........................................19
6.      DATA PLANE MECHANISMS FOR TRAFFIC MANAGEMENT FUNCTIONS........20
6.1     LABEL FORWARDING PARADIGM.....................................20
6.2     CLASSIFICATION................................................20
6.2.1   What is classification and where it should be done............20
6.2.2   Flow Classification...........................................21
6.2.3   Packet Classification.........................................22
6.2.4   Classification results for differentiated services............23
6.2.5   Classification results for guaranteed services................23
6.2.6   Problems with non end-system classifications..................23
6.2.6.1 Classification in presence of IPSEC...........................23
6.2.6.2 Classification in presence of dynamic address assignment......24
6.2.6.3 Classification in presence of dynamic port numbers............24
6.2.7   Classification state maintenance..............................24
6.3     POLICING......................................................25
6.4     MAPPING.......................................................25
6.4.1   Direct mapping................................................26
6.4.2   Indirect mapping..............................................26
6.5     AGGREGATION, MERGING AND DEAGGREGATION........................26
6.5.1   Aggregation...................................................26
6.5.2   Merging.......................................................27
6.5.3   Aggregation and merging of  traffic with service guarantees...27
6.5.4   Deaggregation.................................................28
6.6     QUEUING AND CONGESTION MANAGEMENT.............................28
6.6.1   Queue management..............................................28 



P.Vaananen, R. Ravikanth                                        [Page 3]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


6.6.2   Queuing principles............................................29
6.6.3   Congestion control............................................29
6.6.3.1 Passive congestion control schemes............................29
6.6.3.2 Active congestion control schemes.............................30
6.6.4   Packet scheduling.............................................31
6.7     TRAFFIC SHAPING...............................................31
6.8     LOAD SHARING..................................................32
7.      LABEL SWITCHED PATH GRANULARITIES AND AGGREGATION.............32
8.      LABEL SWITCHED PATH TOPOLOGIES AND ASSOCIATED TM PROCEDURES...33
8.1     POINT-TO-POINT................................................34
8.2     POINT-TO-MULTIPOINT...........................................34
8.3     MULTIPOINT-TO-POINT...........................................34
8.4     MULTIPOINT-TO-MULTIPOINT......................................35
8.5     MULTILEVEL PATHS..............................................35
9.      NETWORK FUNCTIONAL PARTITIONING...............................37
9.1     NETWORK MODELS................................................37
9.2     NETWORK ELEMENT CATEGORIES....................................38
9.2.1   Hosts.........................................................38
9.2.1.1 Enhanced best effort services.................................38
9.2.1.2 Differentiated services.......................................38
9.2.1.3 Guaranteed services...........................................39
9.2.1.4 Participation in MPLS.........................................39
9.2.2   MPLS edge nodes...............................................40
9.2.2.1 Best effort services to customer..............................42
9.2.2.2 Differentiated services to customer...........................42
9.2.2.3 Guaranteed services to customer...............................43
9.2.2.4 MPLS to customer..............................................43
9.2.3   MPLS core node................................................44
9.3     INTERFACE CATEGORIES..........................................45
9.3.1   Interface to non-MPLS networks................................45
9.3.2   Interface inside MPLS network domains.........................45
9.3.3   Interface between MPLS network domains........................45
10.     LSP MAPPINGS TO EXISTING LINK LAYER TECHNOLOGIES..............46
11.     GENERAL REQUIREMENTS FOR LABEL ENCAPSULATIONS.................46
11.1    DIFFERENTIATED SERVICES SUPPORT...............................46
11.2    CONGESTION MANAGEMENT SUPPORT.................................47
11.2.1  Congestion indicator bit......................................47
11.2.2  Examine me bit................................................48
11.3    SUPPORT FOR MULTILEVEL LABEL SWITCHED PATHS...................48
12.     GENERAL REQUIREMENTS FOR DISTRIBUTION OF LABELS AND TM ATTRs..48
12.1    SETUP REQUEST.................................................49
12.2    SETUP MODIFICATION............................................49
12.3    SETUP ACKNOWLEDGE.............................................49
12.4    SETUP REJECT..................................................49
12.5    DISCUSSION OF SIGNALING PROTOCOLS.............................50
12.5.1  General.......................................................50
12.5.2  LDP...........................................................50
12.5.3  RSVP..........................................................51
13.     REFERENCES....................................................51
14.     SECURITY CONSIDERATIONS.......................................54



P.Vaananen, R. Ravikanth                                        [Page 4]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


15.     AUTHOR'S ADDRESSES............................................58

2. INTRODUCTION

The ability of the network to support service level guarantees and 
traffic engineering is becoming very important. This area has been, and 
will remain as subject area addressed in various working groups of IETF 
(e.g. INTSERV, RSVP, ISSLL, RAP, DIFFSERV, IPPM, QOSR), IRTF (E2E), ATM 
Forum (TM), Frame Relay Forum, ITU-T, and various other organisations 
and user consortiums.

We build on the ideas and previous work done in  these working groups, 
and try to build a coherent set of capabilities around the label based 
packet forwarding technology discussed in MPLS working group of IETF, 
as described in MPLS framework document [Callon97] and MPLS 
architecture document [Rosen97a].

The approach taken in this document is to look at the available pieces, 
and try to fit them on to the MPLS framework in a scaleable 
fashion.This document presents a requirements and implementation 
framework in the context of MPLS for the services and capabilities that 
needs to be built. Possible mechanisms and deployment scenarios to 
actually achieve these advanced services are also described.

The document tries to take evolutionary rather than revolutionary 
approach, we don't propose to change everything at once (and do not 
believe it's possible), as previous attempts have quite consistently 
failed to do it.

Focus is to try to answer two questions: what should be done that the 
quality of the network service perceived by the end user improves, and 
how to maximise the usage of the network resources, and at the same 
time do it in scaleable and controlled manner.
 
We feel especially important that the deployment of the technologies 
presented can be started on the small scale, and without changes to the 
host communication and application protocols, while this framework 
attempts to be flexible enough to be able to accommodate such changes 
when the technology matures and the incremental deployment is 
determined to be feasible and necessary.

We hope to evolve the technologies and protocols of the MPLS towards 
supporting the capabilities outlined in this document, but do realise 
that much more detailed discussion, research and specification work 
needs to be done before the complete set of  "wishes" can be 
accomplished.

3. SERVICE CATEGORIES

The advanced services requiring the use of the traffic management 



P.Vaananen, R. Ravikanth                                        [Page 5]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


mechanisms can be broadly divided into three categories on a basis of 
(i) the level of assurance on service guarantees that can be achieved 
and (ii) the granularity of guarantees (simple to complex) that is 
provided. This division is made here to support the discussion of the 
related traffic management issues. 

The characteristics of the different service categories are briefly 
described in the chapters 3.1. to 3.3.

3.1 Best effort services
3.1.1 Enhanced best effort service

The service remains similar to the current best effort service, but 
with the higher service quality perceived by the end-user, regardless 
of the applications used. Enhanced best effort service can be realised 
without specific signalling protocols inside the network. This service 
differs from "plain old best effort" because of the use of the 
advanced congestion control mechanisms. The purpose is to provide a 
more controlled and more fair behaviour during congestion period.

Passive congestion control mechanisms based on packet drop policies, 
such as random early detection [Floyd93], [Braden97] can be used. In 
addition to passive congestion control mechanisms, active congestion 
control mechanisms based on congestion feedback and transport protocol 
interactions have also been suggested [Ramakr97], [Packeteer97], 
[Jagan97].

This service can be implemented in any router with the support of 
appropriate traffic management mechanisms. The use of label based 
forwarding paradigm does add capabilities for the network operator 
traffic engineering, such as better ways to control the path selection 
for the traffic.

3.1.2 Enhanced best effort service with bandwidth allocation

The enhanced best effort service augmented with bandwidth allocation 
capability allows an operator to optimise network capacity usage, and 
manage bandwidth usage by allocating it to individual users, networks, 
or any aggregated community as desired. 

These services generally require a specific signalling protocol for 
communication of the related traffic management attributes through the 
network.

3.1.3 Enhanced best effort services in MPLS environments

Basic enhanced best effort service does not generally require per-flow 
state to be maintained in the network elements, the goal is to support 
fair usage of resources inside network. 




P.Vaananen, R. Ravikanth                                        [Page 6]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


MPLS enables the carrying of congestion indication over the LSP to 
allow the LSP endpoints to react to congestion. In addition, the 
congestion indication can be monitored in the LSP endpoints, and 
information of congestion exceeding some predetermined threshold can be 
used e.g. to initiate the re-evaluation LSP path selection.

In environments where bandwidth allocations are used, any required 
traffic management related attributes that are used are generally 
applied on aggregated streams. The use of label based forwarding 
paradigm adds easy to implement capabilities to allocate bandwidth to 
aggregated best effort traffic streams and provides ways to communicate 
these allocations through the network.

Generally enhanced best effort approaches rely on the interactions of 
the network with end-to-end protocols (e.g. intelligent drop policies) 
to reduce the load at times of congestion. Common practise at a moment 
is to use FIFO type queuing.

Together with the bandwidth allocation capabilities, the path selection 
mechanisms, such as explicit label switched paths provide efficient 
capabilities to network traffic engineering.
3.2 Differentiated services
3.2.1 Differentiated service

Differentiated services are currently being specified in the IETF 
DIFFSERV working group. Work is in an early phase, and there are 
several different proposed approaches.

Differentiated services, as proposed, allow the traffic to be 
classified into finite number of priority and/or delay classes. Traffic 
classified as having the higher priority and/or delay class receives 
some form of preferential treatment over the traffic that is classified 
onto lower class. Differentiated service does not attempt to give 
explicit end-to-end guarantees over the network, instead, in congested 
network elements, the traffic with higher priority class has a higher 
probability to get through, or in case of delay priority, scheduled for 
transmission before the traffic that is not delay sensitive.

Differentiated service packet classification can be performed either in 
the hosts, CPE routers or in the operator network border routers. 

The information required to perform actual differentiation in the 
network elements will be carried in the TOS field of the IPv4 packets, 
referred as DS-byte in differentiated service operational model 
document [Nichols98]. Thus, as the information required by the buffer 
management and scheduling algorithms is carried inside the packet, 
differentiated services do not necessarily require signalling protocols 
to control the mechanisms that are used to select different treatment 
for the individual packets. 




P.Vaananen, R. Ravikanth                                        [Page 7]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


Differentiated services can be implemented in any router that supports 
the appropriate traffic management mechanisms.

3.2.2 Differentiated services with bandwidth allocations

In addition to the basic functionality provided by the differentiated 
services, the addition of the bandwidth allocation capability allows 
the network operator to allocate the desired bandwidth to the switched 
paths carrying the differentiated services over the network domain. 
Depending on how the differentiated service allocations are 
implemented, the operator can either control the bandwidth share given 
to each priority class separately, or allocate bandwidth to 
differentiate service class paths as a whole, and implement 
differentiation on the basis of capability of the resulting virtual 
path.

3.2.3 Differentiated services in MPLS environments

Generally no per-flow state is maintained in the network elements, goal 
is to support a small, fixed number of service categories. 

Per stream attributes distributed using the label distribution 
mechanisms can include the differentiated service category associated 
with the LSP. 

One or more queues with simple service policy are used. In case that 
multiple queues are used to support delay prioritisation, scheduling 
mechanism ensures that the low delay classes are served first. Weighted 
scheduling mechanisms may be used instead of strict priority scheduling 
to ensure that the lower classes cannot suffer of starvation.
 
The support of differentiated services in MPLS environments requires 
signalling support for the association of the desired category with the 
label, or alternatively each packet needs to carry the information of 
the desired service category.

MPLS allows the allocation of  bandwidth for the differential services 
in conjunction of the another services in controlled manner. This 
allows the operator to allocate the available bandwidth between 
differentiated service category and other categories, on LSP basis 
depending on implementation.

3.3 Guaranteed services

These services provide hard guarantees that are explicitly specified 
for different granularities, and topological scopes from network 
boundary to network boundary to end-to-end. Guarantees can be given for 
different kinds of the parameters, such as bandwidth and/or delay, 
depending on the service class and capabilities of the network elements 
on the path. Guaranteed services may be based on the contractual 



P.Vaananen, R. Ravikanth                                        [Page 8]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


guarantees or user-network signalling, such as RSVP. Signalling 
protocol to communicate the service parameter information is required 
inside network. 

In the IETF, guaranteed services have been specified by INTSERV working 
group. Integrated service framework is described in [RFC1633]. There 
are currently two services that have been defined by INTSERV; 
controlled load [RFC2211] and guaranteed service [RFC2212]. These 
services should be supported in MPLS environments. Service parameter 
mappings to different link layers specified in the ISSLL working groups 
should be applicable to MPLS, augmented with the label encapsulation 
procedures specified in the MPLS WG.

3.3.1 Services

Two different guaranteed services have been specified in INTSERV effort 
of the IETF so far:

- Controlled load service [RFC2211]
- Guaranteed Quality of Service [RFC2212]

Other guaranteed service categories that may be applicable to certain 
MPLS environments have been specified by other standardisation bodies, 
such as in Frame Relay Forum and ATM Forum [ATMF96].

The service categories specified in other bodies than IETF are not 
presently discussed in this document, as we attempt to build onto 
present state of the work of the IETF. The service categories from the 
other standardisation bodies may become important in the future, and 
their use in the MPLS context and mappings between IETF services and 
external categories may be specified as part of MPLS effort or other 
IETF efforts, such as ISSLL.


3.3.2 Guaranteed services in MPLS environments

Per-LSP or per-flow state needs to be maintained in the edge MPLS 
nodes, depending on the topological scope of the guarantees, for end-
to-end, flow state is required, and internally, per-LSP state for 
aggregated guarantees needs to be maintained. Aggregated state 
information is needed in the core network elements. 

The implementation of guaranteed services requires the use of the 
advanced queuing mechanisms in the network elements. Signalling support 
for communication of changes of the individual or aggregated state 
information associated with the LSP will be required.

For scalability, the aggregation of the guarantees to form guaranteed 
aggregated label switched paths is desirable. For the implementation of 
the end-to-end reservations, the information of the parameters of the 



P.Vaananen, R. Ravikanth                                        [Page 9]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


aggregated entities are required in the de-aggregation points of the 
network. This can be realised in MPLS by using the multilevel LSPs. 
This requires signalling of the individual constituents of aggregated 
flows from the aggregation to de-aggregation point.

The current methods for QoS on IP seem to have scalability issues, when 
the number of connections requesting such services grows. Thus, an 
issue that is not MPLS specific, is that of making it scalable through 
a combination of aggregation and provisioning. Such aggregation 
techniques may place some requirements on MPLS, to the extent that the 
labels may have to be associated specific kinds of parameters, which 
pertain to the aggregation. Thus the label assignment and distribution 
mechanisms should provide ways for distributing such attributes.

MPLS benefits the implementation of the guaranteed services, as the 
association can be made in the border nodes of the network onto LSPs, 
and the intermediate nodes need only use the label information to 
retrieve the attributes them require to provide the desired guarantee 
for the associated LSP. The use of labels to retrieve the state 
information provides great benefit compared to the model where each 
node in the path would require to keep state of each guaranteed flow, 
and find the flow by matching a filter to each packet to retrieve the 
traffic parameters of the flow.

4. TRAFFIC MANAGEMENT REQUIREMENTS

Requirements presented in this chapter are a superset of requirements 
of those expressed in numerous sources. Some of the requirement sources 
these requirements are based on are [Smith97], [Bradner97], and 
[RFC1633].

4.1 Service category support

- Support for services described in the previous chapter

MPLS shall support the implementation of the services described in 
previous chapter, in such way that the desired set of services can be 
implemented in same node and same link. The implementation of all 
services should not be mandatory, but considered as a differentiator 
between the products. However, the MPLS standardisation effort should 
describe the set of mechanisms to support all of the above services to 
ensure the interoperable implementation of these services.

- Support for controlled link sharing

Network operators shall be able to allocate maximum shares of link 
bandwidth to different service categories, in a such way that the 
minimum amount of bandwidth is guaranteed for each service class. This 
allows the operator to guarantee that the lower priority services 
cannot suffer from the starvation because of the higher priority 



P.Vaananen, R. Ravikanth                                       [Page 10]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


services use all available bandwidth. These setting shall be enforced 
by the policy and admission control together with the policing, queue 
management and scheduling mechanisms. In the absence of the traffic in 
higher priority service classes, the bandwidth should be available for 
use by the lower priority traffic.

4.2 Admission control, monitoring and security 

- Support for authentication

Authentication of the users and/or equipment needs to be performed at 
domain borders to determine that the service user is who he claims to 
be. Authentication is required to support admission and accounting.
 
- Support for admission policies and control

Operator shall be able to apply admission policies in the operational 
network boundary, to enforce the service agreements between the users 
and/or other operator network domains. 

- Support for accounting

When the enhanced service levels are used, the incentive for the 
network operator to provide such services is to get more revenue of the 
consumers of such services. Accounting is required to keep track of the 
services used, and to be able to provide usage sensitive pricing 
policies for enhanced level services.

- Service management

When the enhanced services are provided for the end-user, inside the 
operator's network, or between the domains, it is important for both 
the operator and end-user to be able to monitor that the performance of 
the provided services fulfil their specifications. The required 
measurement and management features shall be implemented on network 
elements and management systems to support these requirements.


4.3 Congestion management

- Congestion control

Congestion control is important even for the best effort services, but 
becomes more complicated when the different levels of services are 
supported over same interfaces. Characteristics of mechanisms and 
guidelines for use of these congestion control mechanisms in multi-
service environments shall be specified.

4.4 Scalability requirements




P.Vaananen, R. Ravikanth                                       [Page 11]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


- Minimisation of the label space requirements

The label space may become a limitation of the applicability of the 
label switching scheme, unless the attention for the constraining the 
label space in architecture design phase is given. Increased label 
space makes the management of the label space more difficult, it 
involves more state keeping in network elements, and implies higher 
dynamics of change in the label assignments or attributes. Adding 
advanced services to pure best-effort delivery will inevitably increase 
the label space requirements, and an attempt should be made in the 
specification phase to minimise the overhead. Aggregation and merging 
are examples of the mechanisms to help in the label space containment.

- Minimisation of the state in the network elements

Flow specific state shall be maintained only on the network elements 
that are required to handle the individual flows, such as edge network 
elements. The design goal is that the core network elements do not 
require to maintain flow specific state information. This enhances the 
applicability of the MPLS in large networks and high-speed backbone 
links.

- Support of the different granularities of control, single flow to 
highly aggregated streams 

It is important that the multiple control levels are supported, 
depending on the level in the network where the services are provided. 
General guideline is that the amount of the state information that is 
required to be maintained decreases from network edge towards the core 
of the network.

- Minimisation of the signalling requirements

The state maintenance associated with the control of the path traffic 
management attributes implies the use of the signalling mechanism to 
convey this information. It is important that the signalling traffic 
required by the traffic management support be minimised.

4.5 Robustness and reliability 

- Soft state protocol

The protocol(s) resulting from the MPLS work should use soft state 
approach as much as possible, i.e. to have the state associated with 
the LSPs required to "expire", if not periodically refreshed. Hard 
state should only be associated with the administratively configured 
LSPs (explicit routes, policies, etc.). Care should be taken that the 
overhead of the state refreshments required to maintain the soft state 
components does not grow excessive, e.g. due to requirement to refresh 
the state of associated with each LSP individually.



P.Vaananen, R. Ravikanth                                       [Page 12]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



- Security considerations

The basic idea of supporting the any kind of service level 
differentiation opens up the possibilities for the user's to try to 
gain access to more valuable services without paying the appropriate 
compensation. In addition, the new kinds of denial of service attacks 
may become possible. Security considerations have to be taken in 
account when designing the architecture and protocols for the traffic 
management aspects.

- Reliability

The service level agreed upon with the customer have to be monitored, 
and the means for alerting the network operator of failures, and 
mechanisms (to possibly automatic) reconfiguring of the switched path 
arrangement inside the network to quickly remedy the failure have to be 
considered. 

4.6 Topology support

- Support for point-to-point topology

Point-to-point topology is conceivably the simplest of the topologies 
that needs to be supported. The basic topology, between the network 
elements is point-to-point path, which can have it's associated 
parameters. More complex topologies can be supported by merging the 
ingress paths to single egress paths with different characteristics 
(aggregation). It shall be possible to support point-to-point LSP's 
with the associated resource allocations and priorities.

- Support for point-to-multipoint topology (multicast)

Point to multipoint topology is useful for the support of the multicast 
data delivery. Point to multipoint topology support shall include means 
for managing the joins and withdrawals of leafs, affecting only the 
associated part of the multicast distribution tree. Also, it shall be 
possible to support heterogeneous receivers in the multicast groups.

- Support for multipoint-to-point topology

Multipoint-to-point topologies are attractive for scalability reasons. 
Single destination based tree can be constructed for traffic that can 
be treated similarly. It shall be possible to support different traffic 
reservations in different parts of the tree, with higher resource 
allocations towards the egress points of the multipoint-to-point 
delivery tree (each merge point adds it's traffic volume to the tree).

4.7 Topological scope
- Support for different topological scopes (inside domain, between 



P.Vaananen, R. Ravikanth                                       [Page 13]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


domains, end-to-end)

MPLS shall consider the different requirements and scalability aspects 
imposed by the different topological scope, and the functional 
partitioning inside MPLS domain and between the MPLS domain and other 
MPLS or non-MPLS domain.

4.8 Compatibility

- Support of current applications without modifications

There have been numerous proposals in the past to provide the enhanced 
services, that involve the modification of the end-user application 
software. Examples of such proposals are end-to-end ATM deployment, use 
of RSVP by the end-user applications to request service guarantees, and 
use of the applications to classify their traffic onto differentiated 
service categories. While such end-to-end guarantees may become 
important later, it shall be possible to initially implement service 
contracts without modifications to applications and end-to-end 
protocols. This can be accomplished by classifying the traffic on the 
network edge's instead of the end-to-end basis, and providing required 
transmission capacity (e.g. dedicated switched Ethernet port) to end-
user's computer system. Additional advantage is the centralised nature 
of the management of these services.

- Interoperability

MPLS should consider the interworking and interoperability of the MPLS 
based network with the currently available networking technologies, and 
also describe the advanced service mappings between the other 
networking technologies and MPLS where applicable.

- Support for different link layer technologies

Mapping of the label switching paths to different link layer 
technologies shall be specified taking into account the traffic 
management capabilities provided by the underlying link layer 
technology, and the desired properties of the supported service set. 
Candidates for the link layers suitable for carrying labelled traffic 
in public network environments include ATM, Frame Relay and MPLS over 
SONET. 

4.9 Extensibility

- Extensibility

Traffic management framework and associated architecture and protocols 
shall be extensible to support new attributes for supporting new 
services without the changes to initial concepts and mechanisms.




P.Vaananen, R. Ravikanth                                       [Page 14]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


- Mechanism independence

The traffic management mechanisms shall be loosely specified, rather in 
the way of specifying the characteristics of the mechanisms required to 
support different parts of traffic management functionality. Mechanisms 
like queue management and scheduling are local in the  network element, 
and thus do not need to be strictly standardised. Suggestions of the 
applicable mechanism should be given, but vendors should have the 
freedom to implement whatever mechanisms they feel appropriate to 
achieving the desired functionality. Additionally, this allows for 
improvements in the individual mechanisms via active research in the 
area. Thus it is important to standardise on the semantics of 
information carried in the signalling protocol (LDP) or that associated 
with individual packets, as applicable. 


5. CONTROL PLANE MECHANISMS FOR TRAFFIC MANAGEMENT FUNCTIONS

This chapter describes the mechanisms required in the various parts of 
the network to control the data plane traffic management functions 
described in the next chapter. These mechanisms include policy and 
signalling aspects required to set up, and to maintain the LSPs.

Note that the location of these mechanisms in the networks is not 
discussed in this chapter, a discussion of the location of mechanisms 
in different network environments is given in chapter 9.

5.1 Triggers

Triggers are events that cause the changes in the LSP configuration. 
These changes may be LSP establishment, reconfiguration, deletion or 
attribute modification. The triggers either require going through full 
or partial LSP establishment process depending on the type of the 
trigger.

Triggers typically result from events  related to changes of some 
information relevant to LSP set-up, such as:

- configuration event
- signalling event
- topology change
- traffic pattern change

The scope of the change initiated by trigger can be either local (i.e. 
inside of the network element), regional (i.e. affects the 
configuration of the peer MPLS nodes) or global (i.e. affects all 
network elements that compose the LSP).

The frequency of the regional and global changes should be minimised. 
As the finer granularity of control of the LSP attributes is required 



P.Vaananen, R. Ravikanth                                       [Page 15]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


(e.g. explicit reservations), this becomes increasingly hard to 
achieve.

Properties associated with different kinds of triggers are discussed in 
sections 5.1.1 to 5.1.3.

5.1.1 Configuration events


A configuration event can affect either policy or LSP configuration 
parameters. Policy changes affect the admission or classification 
policy being used in the node. LSP parameter change affects the 
attributes associated with the statically configured label switched 
path.

The policy related changes can either force the re-evaluation of the 
current classifications or be taken into use gradually, as new paths 
are used. Although the immediate re-evaluation would be desirable, it 
may have negative effects on the performance and the handling of the 
current traffic. 

Parameter changes may require the communication of the change to peer 
LSRs that compose the LSP (signalling initiated by the 'root' node of 
the LSP), or be configured onto each LSR along the path individually 
(management initiated change). In either case, these changes should be 
taken into effect immediately.

5.1.2 Signaling events

Signalling event is an externally received trigger that explicitly 
affects the way LSPs are set, and depending on the signalling event 
type, may results either in setting-up, tearing down or modifying 
attributes of the LSPs.

It can be foreseen that different kinds of signalling protocols will 
need to be supported, depending on the interface the event is received 
from. There will likely be different signalling mechanisms used for 
users, inside a network domain and between domains (e.g. RSVP and LDP).

5.1.3 Topology changes

Topology changes are events that are associated with the changes in 
network topology, and may potentially result in the requirement for 
large number of reconfiguration of a large number of LSPs. Topology 
changes are brought to the attention of the label distribution 
subsystem by the routing protocols and the monitoring of the status of 
the established LSPs.

5.1.4 Traffic pattern changes

Traffic pattern change is an event triggered by the user activity that 


P.Vaananen, R. Ravikanth                                       [Page 16]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


is observed by the network element resulting in the change of the 
traffic characteristics received over interface. Examples include the 
appearance of the new traffic flow, or timeout of the existing flow. 
These changes may affect how the LSPs are set up or attributes of the 
LSPs. Traffic pattern related changes should be attempted to be kept as 
local.

5.2 Policy and admission control

Policies and admission control form a set of processes that directly or 
indirectly control the set-up of the label switched paths through the 
network element.

5.2.1 Routing policy

For the new LDP requests, routing policies applied on the Internetwork 
are the first controlling policy that controls the potential routes the 
LDP paths can take through the network.

Routing policies are thus not directly involved in  the topological 
control of the LDP establishments, but them control the establishment 
basis of the information (routing information base) that the LDP uses 
to determine available routes.

It shall be noted that the current routing protocols use the topology 
and metric information to select the "best" route to use of the 
multiple options, and do not generally know anything about the path 
characteristics or services supported on the path available in the 
routing database.

5.2.2 Classification policy

Classification is based on two categories of information, specifically 
information in the headers of the received packets and the control and 
policy information provided by the configuration (management plane), 
routing and signalling protocols.

IPv4 Header information useable in the classification process:
- Destination address
- Source address
- IP protocol field
- TOS

TCP/UDP header information useable in the classification process:
- Source port number
- Destination port number

Additional header fields may be parts of the classification, if 
desired.




P.Vaananen, R. Ravikanth                                       [Page 17]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


The classifier makes a decision on the basis of the preconfigured 
classification policy information, which specifies the kind of 
treatment the packets belonging to flow would like to receive. Note 
that the classification policy alone does not guarantee that the 
desired behaviour will be achieved, this is further refined by the 
admission policy, admission control and policing functions.

For IP packets, the classification process can be generally 
accomplished by applying the filter template of the form {DA prefix, SA 
prefix, PRO, TOS, SPN, DPN} to each individual packet. Any of the 
fields can be a wildcard, so for example all traffic destined to web 
server would be specified using filter {*,*,6,*,*,80}. In some cases, 
there may be several different filters that may match the same packet, 
and the results of the match for the most specific filter should be 
used in such cases.

In addition to packet header information, local information may be 
added to the classification process. One example of such local 
information type is the interface the packet was received from.

The classification policy determines how the individual flow should be 
treated, including attributes such as the reservation type and 
granularity, differentiated service class, etc. On the basis of the 
filtering result, the packet may be associated with the LSP, or flow 
identifier.
 
5.2.3 Admission policy

Admission policy is the process to determine if the new request for the 
LDP set-up or attribute modification with some set of reservations is 
administratively acceptable. This is administratively configured, and 
is associated with the given granularity entity, such as individual 
user, user community, or peer AS. 

The type and the granularity of the information that will be taken into 
account by the admission policy depends on the interface type, local 
policy and trigger type (e.g. signalling versus configuration event).

When reservation requests of coarse granularity are considered (e.g. 
individual LDP set-up on public network interface supporting a large 
corporation), the admission policies are typically applied against the 
parameters associated with the aggregate set of all reservations 
currently associated with the community, reservation parameters and the 
administratively configured maximum resources allocated to that 
community.

5.2.4 Admission control

Admission control is the process that is used to determine the resource 
availability to support a new request or the modification of attributes 



P.Vaananen, R. Ravikanth                                       [Page 18]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


associated with existing label switched paths. Admission control is 
invoked as a final step, after it has been determined that the route to 
the destination is available, and the permission to process the request 
is granted by admission policy.
 
Admission control gets more complex when the granularity of the 
reservations increases, being not invoked at all for best-effort 
traffic, and being most complex for the guaranteed traffic.

5.3 Path selection

The primary mechanism to control path establishments and deletions in 
MPLS networks is the routing protocol. In addition, paths through the 
network can be established using the explicit routing. Static LSPs can 
be configured through management interface. 

For the MPLS network elements to be able to automatically locate 
alternate paths with the sufficient resources available, routing 
protocols that are able to take in the account additional path 
attributes instead of just topological connectivity and preconfigured 
metrics of the available paths is needed.

The draft framework for QoS routing work effort have been developed in 
QOSR working group of the IETF [Crawley98]. However, the routing 
protocols with suitable metrics to be used in the environments with 
fine-granularity service guarantees inside or between the domains need 
to be developed.

5.4 Accounting

Accounting mechanism is required by the service operators to be able to 
bill users in accordance with the services used. If the accounting 
mechanisms are not in place, there is no incentive for the users to use 
anything but best offered service classes.

MPLS accounting mechanisms shall be able to collect usage data with 
desired granularity (single user to peer operator), together with 
traffic management attributes associated with the LSP, and transfer 
this data to operator's billing system. Protocols used for transferring 
accounting data to billing systems and billing procedures are outside 
of the scope of the MPLS work. Suitable protocols may include e.g. 
RADIUS and TACACS+.

5.5 User authentication

At the moment, these services need to be implemented on the basis of 
the interface, protocol and network address information, but as the 
users are mobile (even within a corporate network), and also because of 
the increasing use of the dynamic address allocation mechanisms, such 
as DHCP and NAT's the ultimate goal should be to base the service 



P.Vaananen, R. Ravikanth                                       [Page 19]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


policies on the user information.

One possible implementation may be based on the use of directory 
services, such as LDAP to store the user profile information, but the 
approach needs to be standardised to be usable in the large scale.

6. DATA PLANE MECHANISMS FOR TRAFFIC MANAGEMENT FUNCTIONS

This chapter describes the mechanisms required in the various parts of 
the network to provide support for the transport of the traffic with 
the service parameters through the network. These mechanisms include 
all the mechanisms that are involved in per packet decisions that are 
performed in the intermediate network nodes. The parameters for 
controlling these mechanisms are determined by the control plane 
mechanisms described in the previous chapter.
 
Note that the location of these mechanisms in the networks is not 
discussed in this chapter, discussion of the location of mechanisms in 
different network environments is given in chapter 9.

6.1 Label forwarding paradigm

In the best-effort label based forwarding, MPLS nodes use the simple 
exact match lookup to determine the egress link where the packet should 
be sent. When the services that require the support for service level 
differentiation are implemented, MPLS node uses the same exact match 
label lookup to determine not only where the packet should be destined, 
but also the additional state information associated with label, 
related to queuing and scheduling of the packet.


6.2 Classification
6.2.1 What is classification and where it should be done

The purpose of the classification process is to determine the queuing / 
scheduling treatment that the packets should get as they traverse 
through the network.

The result of the classification determine the following attributes:

- service class the packet should be carried on, 
- for differentiated services the drop priority and / or delay 
priority for the packet
- for guaranteed services the parameters determining the desired 
service guarantees

Packets may be classified as belonging to different service categories 
in the various places of the end-to-end path traversed.

Likely places where the packet classification may occur are:



P.Vaananen, R. Ravikanth                                       [Page 20]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



- Operator's domain ingress router
- CPE router
- Host

When the hosts performs the classification, it may base the 
classification decisions either on the protocol used (part of the host 
protocol stack), or the attributes communicated from the application. 
Guaranteed service parameters will likely be based on the parameters 
communicated by applications.

When the classification is performed by the routers (either CPE router 
or operator's border router), the classification decisions have to be 
based on the protocol information carried on the packet.

Initial deployment is likely to be based on the classification on the 
routers, as there is no support for performing the classifications in 
the host protocol stacks. When the classification is performed in 
router's, modifications to host protocols and applications are not 
required. Additionally, it is easier to set up administrative 
classification policies when the classification is performed in 
routers.

The stand-alone and integrated equipment for performing the 
classification for controlling the traffic are available at a moment, 
but there are not standard ways to manage these, neither standard ways 
on how the classification results are used to control the data stream. 
One common characteristic of current solutions is that they are usually 
decoupled from the other network equipment. 

Depending on the place where the classification is performed, the 
procedures performed on subsequent nodes do vary.

6.2.2 Flow Classification

Flow classification is the process of associating a label to individual 
traffic flows. This process needs the consideration of the 
classification policy to be able the associate the label with the flow. 
Depending on the aggregation environment, the label may be associated 
with single flow, or if the flow aggregation is supported and suitable 
label already exists, flows may be aggregated to stream on the existing 
label.

The purpose of the flow classification process is to reduce the 
processing load associated on making the decision of which label to 
associate with arriving packets. If the full classification can be 
performed for each packet without performance penalty and the suitable 
label exists, the flow classification is not required. 

Flow classification needs to be performed at least once for each new 



P.Vaananen, R. Ravikanth                                       [Page 21]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


flow. Flow classification is performed on the edge MPLS nodes, where 
the packets from non-MPLS network domain enter onto MPLS network 
domain. This process can also produce the simple key, such as  the 
entry in the hash table to be subsequently used by the packet 
classifier for the faster determination of the label that needs to be 
associated with individual packets.
As more fine-grained control becomes necessary, flow classification 
becomes mandatory, because the accomplishment of fine-grained 
guarantees involve the setting up the new LSP or modifying the 
parameters of the existing LSP.

In some cases, if it is determined that the suitable label for carrying 
the flow does not exist, a new LSP needs to be set up or the attributes 
of the existing LSP needs to be changed. The applications that are 
allowed to do this should be subject to careful consideration, as it is 
preferable to have the LSPs set up beforehand, otherwise the LDP 
modifications done on a per flow basis consume too much resources and 
become the performance / scalability bottleneck. However, this is 
useful for some applications whose characteristics are known beforehand 
to require relatively long lasting flow with service level 
requirements, such as e.g. videoconferencing.

Classification mechanisms that require the edge routers to maintain 
per-flow state information are susceptible to  denial of service 
attracts by malicious users. One can foresee the attack based on 
sending the packets with various destination address / port 
combinations in rapid sequence, causing the per flow state to be 
established for each packet. This can lead to exceeding of the per-flow 
state maintenance and flow establishment handling capacities of the 
routers performing the classification. There is no easy cure against 
such an attack, except administratively limiting the amount of the per-
flow state that is associated with the interface. Together with the 
source address validation, this at least can provide information of 
where the attack originated from.

Note that the flow switching as discussed here is nothing new, this has 
been used in routers and firewalls for long time. For more information 
of flow measurements and classification, see [Claffy95], [RFC2063], 
[RFC1954], [Cisco97]. 

6.2.3 Packet Classification

Packet classification performs the mapping of the individual packets 
onto desired LSPs. Packet classification process essentially assigns 
each arriving non-labelled packet onto suitable label switched path, 
which has to be available before the packet classifier can perform it's 
function.

Prior to the packet classification, the LSP has to have been set up 
using either the flow classification process or other mechanisms, such 



P.Vaananen, R. Ravikanth                                       [Page 22]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


as setting up the LSP on basis of information provided by management, 
topology (e.g. routing protocol) or signalling protocol.

As discussed in the above chapter, flow classification process may help 
packet classification by producing the keys to increase the packet 
classifier performance.

6.2.4 Classification results for differentiated services

For the differentiated services, classification determines the 
differential service attributes, such as drop precedence bit values and 
delay precedence bit values. In cases where these attributes differ 
from those carried in the received IP packet header, the received 
header bits may be overwritten or depending on the implementation of 
the diffserv support in MPLS, left alone. 

If the differentiated services attributes are allocated on per LSP 
basis, then the attributes are associated with the label switched path, 
and the result of the classification process should be the label to 
that path.

6.2.5 Classification results for guaranteed services
For the guaranteed services, the label for the LSP that has the 
associated reservation attributes may be the result of the 
classification process. 

Alternatively, in fine-grained flow based systems, the flow identifier 
which can be used to determine it's individual traffic characteristics 
may be the result of the classification process. In this case, these 
are mapped to aggregated LSP by mapping function following the 
classification function.

6.2.6 Problems with non end-system classifications

There are some known problems in performing the classifications in 
intermediate network elements, which are discussed below. 

Whether these present a problem, and if so, the extent of the problem 
depends on the environment the classification function is performed, 
and needs to be addressed in case-by-case basis.

6.2.6.1 Classification in presence of IPSEC

When the transport protocol headers are encrypted, as described in 
IPSEC document "IP Encapsulating Security Payload (ESP)" [RFC1827], 
the transport layer (UDP/TCP) header information, such as port numbers 
cannot be used as parameters for determining onto which flow the packet 
belongs to.

This implies that the classification has to be performed before the 
encryption is applied, in the customer customer device (typically host, 


P.Vaananen, R. Ravikanth                                       [Page 23]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


router or firewall) that performs the encryption process.

Also, as the per flow information is not available in the public 
network, it is possible to run MPLS all way to subscriber and use the 
label to identify IPSEC encrypted flow encapsulated onto one label. 
This way, it would be possible for the operator to enforce the 
requested parameters on per encrypted flow basis. 

It is also possible to achieve this using the RSVP signalling to the 
user, using the IPSEC extensions specified in [RFC2207], which 
basically uses SPI instead of the destination port number to identify 
the flow.
 
6.2.6.2 Classification in presence of dynamic address assignment

The increasing use of the dynamic assignment of the IP addresses make 
it hard to determine the end-system the packets originated from. 
Dynamic address assignments are common in the environments that employ 
DHCP, or NATs.

If the end-system address is important part of the classification 
policy, then the means to communicate the address - physical system 
mappings to classifier needs to be arranged. One possible way to 
achieve this in DHCP environments might be to have DHCP/DNS mapping in 
use, and resolve IP addresses on basis of DNS bindings.

In environments, where the classification is based more on the protocol 
information carried in the packets, dynamic address assignment is not 
problem. This is due to the fact that the dynamically assigned 
addresses are expected to be same for the duration of the session, and 
the flow classifier can still use these addresses for identifying 
individual sessions.

6.2.6.3 Classification in presence of dynamic port numbers

Some applications assign the port numbers they use dynamically, and it 
is very difficult or even impossible to make the correct classification 
on basis of such assignments. For such environments, it appears that 
the easiest way to achieve the correct classification is to let host 
determine the desired classification.

6.2.7 Classification state maintenance

Classification state maintenance process is related to the deletion of 
the per flow state and associated LSP bindings that are not required 
anymore. Examples that lead to the removal of classification state are 
flow time-out, ending of the individual flow recognised by other means 
(e.g. TCP FIN) or signalling event to signify the end of reservation 
request.




P.Vaananen, R. Ravikanth                                       [Page 24]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


Classification state maintenance activities ensure that the non-used 
flow state information is deleted with appropriate intervals to free up 
the resources in network elements. Classification state maintenance 
activity shall be mostly local to the MPLS node. Only when the 
reservations are made on individual flow basis, this affects the LSP 
bindings between peer MPLS nodes. 

If the reservation type for the flow was guaranteed reservation, and 
the flow was aggregated on the LSP with other guaranteed flows, state 
maintenance activity triggers the modification of the reservation 
attributes of the LSP the flow was mapped onto, but does not result in 
teardown of the LSP.

6.3 Policing

In the environments, where the packet classification is performed by 
the end-user's router or user's computer, it is important for the 
network operator to be able to enforce the traffic contract to disallow 
the users to exceed their contractual limits for the advanced services. 

This is performed using mechanism called traffic policing, which 
monitors the user's traffic. The policing function can, depending on 
the service used, either drop packets, or move the packets to lower 
priority or best effort delivery class.

An alternative for the using policing is to allow users send whatever 
they want, and meter the usage of different services and bill the user 
based on what enters the public network. 

However, one likely alternative is to use a combination of these 
mechanisms, so that the user can send up to some maximum value 
specified by the traffic contract per class / service, and get billed 
on basis of combination of basic fee and usage.

In cases where the classification is performed by the operator, the 
traffic contract can be enforced as part of the classification process.

Policing actions can be taken at several granularity levels. Policing 
can be made for individual flows, when the per-flow reservations are in 
effect. Operator likely wants to police on basis of aggregated traffic 
contract on customers interface, and on MPLS network boundaries 
policing can be based on the individual LSP parameters.

6.4 Mapping

On the basis of the flow identification performed by the classifier, 
the mapping process maps the packets to appropriate label switched 
path. This process is configured taking into account the traffic class, 
attributes associated with the flow and the topology information.




P.Vaananen, R. Ravikanth                                       [Page 25]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


The mapping function is responsible for achieving the aggregation. 
Depending on the traffic class, two styles of  mappings can exist; 
direct and indirect mapping.

6.4.1 Direct mapping

Direct mapping can be used when the reservation does not have explicit 
guarantees, like bandwidth associated with it. Traffic classes suitable 
for direct mapping are best effort and differentiated services without 
bandwidth allocations.

In direct mapping, the association is done directly from the packet 
classifier outcome to the desired LSP. 

6.4.2 Indirect mapping

Indirect mapping needs to be used when the reservation does have 
explicit guarantees, like bandwidth associated with it, and the 
aggregation of these is desired.

The need for the indirect mapping arises from the requirement to 
maintain per reservation state so that the individual reservation and 
its associated resources can be removed from the aggregate LSP. The 
reservation state deletion shall commence immediately after the end of 
reservation is detected, either through timeout, determined by 
observing transport header bits, or as result of signalling event.

The associated parameter changes in the LSP configuration may be made 
more infrequently, especially when the frequency of the individual 
reservation establishments and deletions associated with given 
aggregated LSP is high and the reservations are relatively homogenous. 
This reduces the signalling load between the MPLS nodes the along the 
LSP.

6.5 Aggregation, merging and deaggregation
6.5.1 Aggregation

Aggregation means that multiple flows that are treated similarly in the 
network are associated onto same label. Depending on the supported 
service type, the effort to support aggregation ranges from 
straightforward to very complicated.

General guidelines for the aggregation to meet the scalability 
requirements suggest that the all flows that can be aggregated onto 
same label should be aggregated.

Aggregation is the process that is performed at the first place the 
packet classification is performed, and involves the association of the 
different packets that belong to same forwarding equivalence class the 
same label.



P.Vaananen, R. Ravikanth                                       [Page 26]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



Aggregation conserves label space, as the labels do not have to be 
associated with the individual traffic flows.



Figure 6.5.1. Aggregation

Consider the node depicted in the figure 6.5.1. Traffic arrives from 
non MPLS network interfaces (not labeled) and is mapped onto LSPs. 
Because of the aggregation, the number of outgoing LSPs is reduced. 

6.5.2 Merging

Merging is also a form of traffic aggregation, but is performed to 
label switched paths, instead of the individual packets. In merge 
capable node, packets coming from multiple ingress LSPs belonging to 
same forwarding equivalence class are sent out on the single label 
switched path. 

The merging process helps to conserve the label space, and also reduces 
the amount of the connection state that needs to be maintained in the 
intermediate network elements. 

 

Figure 6.5.2. Merging


6.5.3 Aggregation and merging of  traffic with service guarantees

Aggregation of the traffic with service guarantees itself is not a 
problem, the problem is to come up with the associated service 
parameters for the aggregated path, in such way that the minimum amount 
of the resources are reserved, and the guarantees of individual 
reservations are maintained through the aggregated path.

Aggregation of the traffic with just bandwidth guarantees is relatively 
straightforward; the attributes of the resulting aggregated label 
switched paths can be computed on basis of the guarantees given for the 
individual paths or flows that are aggregated.

The computation of the aggregate path parameters can be based on simply 
a sum of the attributes of flows or paths that the aggregate is 
composed of, or can take in the account additional factors like 
oversubscription factor.

When explicit guarantees for both delay and bandwidth are given, 
aggregation becomes much harder, especially if the delay requirements 
are tight. Several aggregation strategies for traffic both with and 



P.Vaananen, R. Ravikanth                                       [Page 27]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


without delay guarantees are considered in references[Schwantag97], 
[Guerin97], [Berson97] [Rampal97], and [Li98].


6.5.4 Deaggregation

Deaggregation is the opposite to aggregation and merging, in the sense 
that it terminates the label switched path and performs layer three 
lookup for the individual packets to determine their next destination. 

Deaggregation can associate the packets either with new label switched 
path, or to the interface to non-MPLS network.

Note that the service class related information associated with the 
labeled packets is not lost in the deaggregation, because the 
attributes of the LSP the packet arrived on are available at the 
deaggregation point. 

If the LSPs are constructed through the MPLS domain, from a set of 
domain ingress interfaces to a single domain egress interface, and 
packets not associated with this egress interface are not merged or 
aggregated to same LSP, deaggregation process is not needed. In such 
cases, if the interface is to a non-MPLS domain, the MPLS header is 
simply removed.

 

Figure 6.5.4. Deaggregation

6.6 Queuing and congestion management

6.6.1 Queue management

Queue management mechanisms manage the available queue space, and also 
determine the appropriate handling of the arriving packet, on the basis 
of the label switched path the packet is received on and the status of 
the desired queue.

Queue management is closely related to congestion control, as 
congestion can be loosely defined as a condition where the queuing 
point on the network element has exceeded or is about to exceed its 
allocated queue space, forcing the packets be dropped instead of queued 
for resource.

Packet handling decisions include which queue packet should be queued 
on, and also whether the packet should be approved onto that queue, 
moved to lower priority queue or dropped.

Note that the moving of the individual packets between the different 
queues is not necessarily a good course of action, unless all packets 



P.Vaananen, R. Ravikanth                                       [Page 28]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


of same flow are put to same queue. This is because the moving of the 
individual packets of the flow to lower priority queue is likely cause 
the packet re-ordering.

Since the queuing mechanisms vary on the basis of the supported 
services and are local onto network element, they need not be subject 
to standardisation efforts.

6.6.2 Queuing principles

Various queuing principles can be used for achieving the support of the 
required traffic classes. Properties of some possible principles in 
order of increasing complexity are discussed below. 

All of these queuing principles can be implemented for both cell and 
packet switching fabrics.

- Single FIFO queue

All traffic is queued onto single queue. Packets are queued together 
with their associated labels. Packets are admitted in the queue on the 
basis of a combination of parameters, such as packet class, queue 
occupancy level, LSP reservation parameters and measured throughput per 
LSP. Packets are scheduled for transmission in the order them arrived. 
Property of this queuing scheme is that the delay cannot be minimised 
for the packets that require that.

- Multiple FIFO queues

Traffic is queued in multiple queues (minimum of 2) on the basis of 
delay priority. Packets are scheduled in priority order, possible along 
with guarantee for the minimum service rate specified on per-queue 
basis. Packet admission onto queues is as before.

- Shared queuing on per label basis

Traffic is queued different logical queues on basis of the arriving 
label. Packet admission to queues is based on the occupancy level of 
each logical queue and possibly overall queue space. Requires complex 
queue space management algorithms as well as advanced scheduling 
mechanisms. This is functionally equivalent to per-VC queuing in ATM 
switches.

It is unclear whether the per-label queuing has enough benefits over 
multiple FIFO queues with admission control to warrant the extra 
implementation complexity.

6.6.3 Congestion control
6.6.3.1 Passive congestion control schemes




P.Vaananen, R. Ravikanth                                       [Page 29]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


Passive congestion control schemes are based on dropping of the packets 
when they arrive at the congestion point. Passive schemes rely on the 
end-to-end protocols to find out that the packet loss has occurred and 
retransmit the dropped traffic with reduced traffic.

Most of the Internet at a moment relies exclusively on the use of the 
passive congestion control schemes. TCP congestion control algorithms 
have been designed to act exclusively on the basis of packet loss 
information.

Over time, numerous algorithms for the more intelligent drop policies 
have been developed, examples include RED [Floyd93], W-RED, and CBQ. 
These algorithms attempt to increase fairness of the usage of congested 
resource, to provide preferential treatment (typically more likely to 
get accepted onto queue) for some portion of the flows or to increase 
the end-to-end throughput in congestion conditions..

6.6.3.2 Active congestion control schemes

While passive congestion control algorithms do certainly work, one of 
their characteristics is that they waste network resources, as the 
traffic first is transmitted onto the congestion point, where it is 
dropped, and then retransmitted later. Dropped packets thus introduce 
extra overhead in the network portion before the congestion point.

To avoid these disadvantages, there have been proposals to make the 
congestion control more active. The goal of the active congestion 
control approaches is to reduce or eliminate the packet loss due to the 
congestion, or to push the drop point towards the point originating the 
traffic.

By active congestion control, we mean that the network more directly 
informs the traffic sources of the congestion situations, and more 
importantly even before the congestion actually occurs. 

These mechanisms are based on the explicit monitoring and notification 
of congestion state along the path the traffic is traversing. The 
notification can be either direct using explicit semantics to tell the 
end-station to slow down, or indirect, using the congestion information 
to influence congestion management mechanisms of the transport 
protocols to control the rate of the sender.
 
The direct mechanisms have been attempted in the real networks, but 
with little success so far, because the lack of the support of the end-
station transport protocols. It has been shown that these schemes work 
reasonably well, when implemented end-to-end. 

Examples of the direct congestion control mechanisms include frame 
relay congestion notification mechanism [I370], ATM binary and explicit 
feedback mechanisms [ATMF96], and proposal for inclusion of the 



P.Vaananen, R. Ravikanth                                       [Page 30]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


explicit congestion notification for IPv4 and IPv6 [Ramakr97]. 

The natural place to carry the congestion notification information in 
MPLS networks would be as part of the label encapsulation header (when 
MPLS is mapped to Frame Relay and ATM environments the existing 
mechanisms to carry congestion information could be used).

However, as the huge installed base of the existing applications is 
built on top of TCP and UDP, more attractive way is to provide direct 
feedback inside the network, and indirect feedback in the network 
interworking point, taking advantage of the characteristics of the 
current transport protocols. Examples of schemes that could be used to 
achieve indirect control are [Packeteer97] and [Jagan97]. 

The advantage of having the direct control inside network is that when 
the transport mechanisms evolve to be better able to take advantage of 
this functionality, the direct control can be extended to the end-
stations.

6.6.4 Packet scheduling

Scheduling algorithms determine the order in which traffic waiting in 
the queues are scheduled for transmission. Scheduling decisions are 
based on the queue specific information e.g. queue priority, weight, 
state, etc.

The need of complex scheduling mechanisms depends on the capabilities 
provided in the network element, such as shaping, multiple service 
class queues, and complex queuing policy. 

In FIFO based queuing systems scheduling is trivial (transmit when you 
have the opportunity).
 
6.7 Traffic shaping

Traffic shaping is the process of modifying the traffic characteristics 
to conform to desired traffic profile. 

Shaping can be used in various parts of the network to make sure that 
the resulting traffic conforms to the traffic contract, and thus has a 
better chance not to get discarded by the policing or congestion 
control mechanisms in the network.

Traffic characteristics tends to get modified by the network, as the 
multiple traffic streams interact, and traffic goes through buffer and 
scheduling algorithms. The process of shaping inside the network to 
make traffic to better conform to its original profile is called 
reshaping.

Examples of the possible shaping points are end-station, MPLS edge 



P.Vaananen, R. Ravikanth                                       [Page 31]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


node, or MPLS core node. 

Shaping can be associated with any granularity, which has defined 
traffic characteristics, from application flow to aggregated label 
switched path.

Shaping may be achieved as part of scheduling functionality.

6.8 Load sharing

Load sharing can be implemented with MPLS routers using the path 
selection based on the load on the available links, and splitting the 
aggregated streams that are associated with different LSPs to different 
available links. 

The load sharing is especially important because of emergence of the 
Dense Wavelength Division Multiplexing (DWDM) systems, because these 
essentially divide the same fiber to up to tens of different channels 
going to the same destination node. Efficient load sharing allows the 
tight integration of the routed traffic and the transmission 
capabilities. Some of the issues related onto integration of optical 
networks and Internet are discussed in [Touch97].

MPLS based load sharing has advantage over the conventional router 
based load sharing, because it can take in the account also where the 
packets originated from, unlike the typical conventional routers. 
Without the knowledge where the traffic came from, it is not possible 
in the receiving node to easily guarantee that the packets are sent in 
the same order as they were sent in the previous node. Packet 
reordering causes performance degradation problems with TCP and some 
other transport protocols.

The concept of the individual flows in the network ingress and/or 
egress points also allows to implement the load sharing for example to 
web server farms in such a way that the packets of the same session are 
always directed to same server.

7. LABEL SWITCHED PATH GRANULARITIES AND AGGREGATION

The subset of the flow granularities defined in the section 2.2.2 of 
the MPLS Framework document [Callon97] appears below, with discussion 
of their applicability on context of traffic management mechanisms 
discussed in this document.

- PQ (Port Quadruples) 

Same IP source address prefix, destination address prefix, TTL, IP 
protocol and TCP/UDP source/destination ports. 

This defines a single communication session between two hosts, and is 
generally referred as "flow". 


P.Vaananen, R. Ravikanth                                       [Page 32]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



While the recognition of existence of individual flows can be important 
at the network boundaries and hosts, per flow state should not be 
required at the core network elements, as it quickly yields to 
unmanageable amount of state information to be maintained in high-speed 
backbone links. This is the reason for the need of aggregation.

- PQT (Port Quadruples with TOS) same IP source address prefix, 
destination address prefix, TTL, IP protocol and TCP/UDP 
source/destination ports and same IP header TOS field (including  
Precedence and TOS bits).

This augments the definition of the flow to take into account the TOS 
byte of the IPv4 packet. It is basically possible for the current 
applications to use different TOS values for different packets, 
although the practise is not likely to yield to any predictable 
results, as the TOS byte is not widely supported as part of forwarding 
process in current routers. 

The differentiated services working group will define the standard 
semantics for this byte, but if the single session uses different 
values it is likely to yield to packet re-ordering problems in the 
network.

For the coarser granularity paths, the aggregation rules should take 
into account the topological scope and the traffic types. MPLS nodes 
should attempt to aggregate the same type of traffic onto same LSP.

It should be noted that the support of the managed paths and different 
services is going to increase the label space consumption, but the 
aggregation should be used to minimise this increase. 

See chapter 8.5., "Multilevel paths" on discussion on how the use of 
multilevel paths can help on the aggregation of traffic with explicit 
guarantees.

8. LABEL SWITCHED PATH TOPOLOGIES AND ASSOCIATED TM PROCEDURES

Services are implemented by assigning attributes to label switched 
paths. The path is composed of point-to-point segments between adjacent 
MPLS nodes. 

In complex topologies (excluding point-to-point) each individual 
segment may have different values for its attributes, depending on the 
location of the segment along the path and the topology of entire path. 
This is also true when the flows with resource allocations are 
aggregated to stream that is associated with the same LSP.

Properties of the different LSP topologies and related traffic 
management issues are discussed in the following chapters.



P.Vaananen, R. Ravikanth                                       [Page 33]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



8.1 Point-to-point

Point-to-point LSP is the simplest of the label switched path 
topologies, and this is the basic building block of all LSPs. 

In this document, point-to-point LSPs that have their own labels and 
attributes, and both the label and its associated attributes have local 
significance between the MPLS network elements. These local LSPs are 
called segments in this document.

In the simplest case, where the end-to-end LSP with the attributes is 
built by concatenating a set of these segments, all segments have the 
same attributes, while the label has only the local significance 
between neighbour MPLS nodes. 

More complex topologies can be constructed by concatenating the 
segments and using traffic merge (mpt-pt) and copy operations (pt-mpt) 
in the network elements to achieve the desired topological LSP 
constructs. 

8.2 Point-to-multipoint

Point to multipoint topologies can be constructed using the packet copy 
function at  the ingress point-to-point LSP segment on the MPLS network 
element. The incoming packets are duplicated for each outgoing label 
switched path. 

Point to multipoint topologies are important for supporting of the 
multicast packet delivery.


8.3 Multipoint-to-point

Point to multipoint topologies are important for scalability reasons.

Multipoint to point topologies can be constructed using the packet 
merge function at the MPLS network element. The incoming packets from 
multiple ingress label switched paths are merged onto same outgoing 
label switched path. 

In addition to aggregating the traffic destined onto single 
destination, in the presence of traffic with explicit guarantees, 
aggregation of the traffic parameters to get the attributes for each of 
the LSP segment composing the multipoint to point tree is required for 
supporting aggregation of the traffic with explicit guarantees. Note 
that this can yield for the different segment to get different 
attributes as the traffic is merged onto the shared multipoint-to-point 
tree.




P.Vaananen, R. Ravikanth                                       [Page 34]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


8.4 Multipoint-to-multipoint

Multipoint to multipoint topologies cannot be directly constructed 
using the same labels, but these can be constructed using desired 
combination of point-to-point, multipoint-to-point and point-to-
multipoint LSPs. Exact decomposition to simpler topologies depends on 
the desired connectivity in multipoint to multipoint topology. Traffic 
management requirements of such simpler topologies can be treated as 
for the simpler topologies used. 

For example, full mesh connectivity between set of endpoints can be 
achieved using multipoint-to-point LSPs, with each endpoint acting as a 
receiver of separate multipoint to-point tree. 

8.5 Multilevel paths

Multilevel paths can be constructed using multiple labels on stack, or 
alternatively partitioning the label space to represent different 
levels (like VPI/VCI in ATM networks). 

The operations associated with label stacks are described in the MPLS 
framework document [Callon97] and label stack encoding proposal is 
described in [Rosen97b].

The routing and scheduling decisions of the packets encapsulated on the 
on multilevel label switched path are performed on the basis of the top 
level label.

Termination of the multilevel LSP is performed in deaggregation point, 
where the top level label is removed (referred as label pop in 
[Callon97]). Second level label is then available for use as the basis 
for routing and scheduling mechanisms.

Multilevel paths are useful when the several paths with similar, but 
different service guarantees are aggregated onto same path. At the 
deaggregation point, the path characteristics of the individual 
aggregated paths that the higher level path is composed of can be 
determined on the basis of second level label.

 

Figure 8.5. Multilevel path example

Consider the simple MPLS network composed of four nodes A-D depicted on 
Figure 8.5. 

There are two traffic sources with reservations entering node A, from 
non-MPLS domains. These two sources are aggregated and leave node A on 
LSPx. 




P.Vaananen, R. Ravikanth                                       [Page 35]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


At node B, the additional LSP (LSPy) that is destined towards same node 
is merged to  same LSP, and the combination leaves node B as LSPz. 
Original labels are pushed to the label stack, and traffic leaves node 
B with top level label LSPz.

At node C, no traffic is either merged or removed from the LSPz, LSP 
label just gets replaced and traffic leaves the node C with new label 
LSP z'.

The traffic arrives at node D, which deaggregates the traffic to it's 
constituents LSP's, denoted as LSP y' and LSP X'.

Now consider that all of the traffic entering and leaving the network 
has reservations. The capacity of LSPx is thus function of RES1_in and 
RES2_in. The capacity of aggregated LSPz is function of LSPx and LSPy, 
which at least LSPx is aggregate.

As the node C does not modify the aggregate in any way, it does not 
need to know the parameters of the individual components the aggregate 
LSPz  is composed of. 

Node D, which acts as deaggregation point for LSPy' and LSPx' needs to 
know the traffic attributes of both original LSPy and LSPx, but it does 
not need to know anything about the parameters of RES1_in and RES2_in.

Compared to the model where each path requires the individual LSP 
through the network, the use of aggregation and multilevel paths can 
save significant amount of state information and signalling overhead in 
the network The use of the multilevel labels enables the de-aggregation 
point still distinguish between different sources received in the 
aggregated LSP and to treat the traffic according to their original 
reservations.

For this to be possible, there needs to be signalling mechanism between 
the aggregation point and deaggregation point to communicate the 
traffic attributes of the second level labels that are deaggregated. 
Note that this does not mean that the deaggregation point does need to 
know attributes of all individual LSPs, that are aggregated, 
deaggregated LSP may still be aggregate on other level. 

Also, if there are large number of aggregated flows on single LSP, and 
there is deaggregation point that needs to split the traffic to number 
of the aggregated egress LSPs, the deaggregation point only needs to 
know which of the second level flows should be associated with which 
egress aggregate LSP, and the total aggregate value of  each egress 
aggregated LSP. 

Large benefits can be achieved at the backbone level, by aggregating 
all the traffic with reservations with similar characteristics onto 
same LSP.



P.Vaananen, R. Ravikanth                                       [Page 36]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



The backbone nodes need only know the reservation parameters of the 
aggregated traffic, not the parameters of individual second level LSPs 
that compose the aggregate. Signalling protocol needs to be run between 
the sending and receiving domain to be able sort out the individuals in 
the receiving end, but the backbone does not need to be participating 
in this signalling other than carrying the signalling messages. 

The attributes of the aggregated LSP can either be modified on basis of 
changes of the constituents of aggregate, but up to single message per 
change is required to achieve this.  Additionally, if this results in 
rapid changes to aggregate attributes, this can be dampened e.g. by 
having the threshold of the minimum change to aggregate attributes that 
needs to happen before the aggregate parameters are signalled to be 
changed

9. NETWORK FUNCTIONAL PARTITIONING

For the purposes of this document, we divide the network elements into 
four categories, hosts, CPE routers, operator border MPLS nodes and 
core MPLS nodes. Note that this is just simple model to facilitate the 
discussion in this document, there is no any reason that the roles of 
these network elements cannot be combined.

Edge MPLS nodes are the nodes that connect the MPLS aware network 
domain to non-MPLS aware domain. Example of such element would be 
border router connecting the users attached with Ethernet to the MPLS 
aware core network domain.

Both CPE routers and domain border nodes are discussed as MPLS edge 
nodes, as their characteristics can be quite same, depending on the 
protocols and extent of the MPLS reaches to.

Domain border MPLS nodes are the special cases of the edge MPLS node 
that connect the two MPLS aware domains together.

Core MPLS nodes are the MPLS nodes in the core of the network, that are 
connected only to the other MPLS nodes; to the edge MPLS nodes and / or 
to other core MPLS nodes.

9.1 Network models
 
Figure 9.1-1. Public MPLS network domain interface

Figure 9.1.-1 depicts the interface between the MPLS network operator 
and operator's subscriber network. Subscriber is connected on the MPLS 
border node, and depending of the environment can support different 
service categories and run different protocols towards the subscriber's 
domain. The partitioning of functionality of CPE router and operator 
border router in different situations is discussed in section 9.2.2.



P.Vaananen, R. Ravikanth                                       [Page 37]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



9.2 Network element categories

This chapter defines the roles of the different MPLS nodes in the 
network, and identifies some basic functionality that these nodes need 
to perform to be able to support the traffic management. 

For the purposes of this discussion, functionality is divided between 
hosts, edge MPLS nodes and core MPLS nodes.

The basic assumption is that instead of using the label information 
just to make a forwarding decision, MPLS nodes capable of supporting 
differentiated services will use label information also as a part of 
the scheduling decision.

9.2.1 Hosts
Hosts are initially likely to be just as they are at a moment, i.e. not 
supporting anything more than the best effort application. In the 
future, hosts may participate in diffserv packet classification or 
support signalling mechanism, such as RSVP to request explicit service 
guarantees. 

It is also possible that at the some point, hosts participate on the 
label distribution protocol.

All of the above functions for the hosts, except the best effort 
communication capabilities shall remain optional.

For the different service categories, the functions that the hosts can 
implement in the future are detailed in the chapters 9.2.1.1 to 
9.2.1.4.

9.2.1.1 Enhanced best effort services
To be able to take advantage of the enhanced best effort service 
provided by the network, the modifications to current host TCP/UDP 
protocols are not necessarily required.

If the explicit congestion indication information is provided by the 
network, modifications to the host transport protocol stack allow the 
host to react to the congestion feedback information received from the 
network.

9.2.1.2 Differentiated services
To be able to take advantage of the differentiated services provided by 
the network, the modifications to current host TCP/UDP protocols are 
not necessarily required. Host may optionally participate on the 
differentiated services process by performing the packet classification 
for the traffic originated from the host. 

This is not necessary however, as the flow / packet classification to 



P.Vaananen, R. Ravikanth                                       [Page 38]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


differentiated service classes can be also performed on the router.

Hosts that actively participate on the differentiated services 
processing have to support the following mechanisms:

- Classification policy (Mandatory)
- Packet Classification (Mandatory) 
- Classification state maintenance (Mandatory)

Hosts that actively participate on the differentiated services 
processing may additionally support some of the following mechanisms:

- Flow Classification (Optional)
- Traffic shaping (Optional)
- Scheduling (Optional)

9.2.1.3 Guaranteed services
To be able to take advantage of the guaranteed services provided by the 
network, the modifications to current host TCP/UDP protocols are not 
necessarily required. Host may optionally participate on the guaranteed 
services environment by running the signalling protocol to request the 
explicit guarantees from the network.

This is not required, as the flow / packet classification process run 
on the router can also make the appropriate requests to the network on 
the basis of the header information of the packets received by the 
host.

Hosts that actively participate in the guaranteed services processing 
have to support the following mechanisms:

- Signalling protocol to request the service (Mandatory)

Hosts that actively participate on the guaranteed services processing 
may additionally support some of the following mechanisms:

- Traffic shaping (Optional)
- Scheduling (Optional)
- Flow Classification (Optional)

9.2.1.4 Participation in MPLS 
Host may desire to participate on MPLS domain by running the LDP 
protocol to request and terminate the paths through the network, 
possibly with some attributes associated with the requested paths.

The additional advantage of the host participation may be that, high-
performance hosts may use the flow labeled LSPs to cache the state 
information inside the host protocol stack to increase performance by 
speeding up or bypassing some of the multilayer protocol stack 
processing. The unwanted effects of multilayer multiplexing are 



P.Vaananen, R. Ravikanth                                       [Page 39]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


discussed in [Tennenh89].

Because the hosts have limited information of the overall network 
topology and the aggregation strategies used by the network, hosts 
should only participate by originating and terminating the LSPs with 
the fine granularity. Aggregation and deaggregation functions should 
thus be left to the network.

Host that actively participates in the MPLS have to support the 
following mechanisms depending on the services used:

- LDP processing (Mandatory)
- Classification policy (Mandatory)
- Packet Classification (Mandatory) 
- Classification state maintenance (Mandatory)

Hosts that actively participate on the MPLS may additionally support 
some of the following mechanisms:

- Traffic shaping (Optional)
- Active congestion control (Optional)
- Scheduling (Optional)
- Flow Classification (Optional)

In addition, hosts may choose to participate in the Intserv environment 
that is also MPLS capable, and use the RSVP to carry labels with the 
reservations.

Note that there are important security considerations that generally 
make it infeasible for the untrusted hosts directly participate on the 
operator's LDP domain in any way, discussed in more detail in section 
9.2.2.4.

However, for the operator owned "trusted" servers, such as web 
hosting facilities, etc. host participation may have some performance 
advantages.

9.2.2 MPLS edge nodes

In this context we include both CPE router and operator's MPLS domain 
in discussion as edge nodes, as the traffic management functionality is 
somehow divided between these two nodes, and the mechanisms described 
in sections 5 and 6 of this document apply to both. 

An MPLS domain edge node contains interfaces to non-MPLS networks, as 
well as to MPLS network domain. There are different scenarios that 
determine how the functionality between the public operator's MPLS 
border node and the CPE node needs to be divided.

 



P.Vaananen, R. Ravikanth                                       [Page 40]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



Figure 9.2.2. Implementation framework for MPLS edge node TM 
functionality, ingress

The functionality and the implementation framework of the MPLS domain 
edge node is depicted in Figure 9.2.2.

As a summary of the functionality that needs to be performed at the 
ingress point of the MPLS domain, the following list applies:

Mandatory functions for operator border router:

- Admission policy
- Admission control
- Direct mapping
- Indirect mapping
- Either of two: flow policing or LSP policing
- Aggregation
- Deaggregation
- Queue management
- Queuing
- Scheduling
- Label distribution

Mandatory functions in either CPE equipment or operator's border 
router:
 
- Classification policy 
- Packet classification 
- Classification state maintenance

Remaining functions, that are optional, may be performed in hosts, CPE 
router, operator MPLS border router, or not implemented at all:  

- Flow classification 
- Flow policing 
- Merging 
- Congestion marking 
- Shaping

An MPLS network ingress point, as viewed from the MPLS domains side has 
to classify the traffic according to the desired service categories and 
allocate the traffic to the LSPs.

This association between the packets at the domain ingress point and 
the label switched path with path attributes determines how the packet 
will be treated in all subsequent network elements in the LSP 
associated with the label. In addition, ingress MPLS node has to 
enforce the traffic contract between the subscriber and the public MPLS 
domain operator and participate on the label distribution process. More 



P.Vaananen, R. Ravikanth                                       [Page 41]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


detailed descriptions of the above listed functions are given in 
sections 5 and 6 of this document. 

Note that from the direction of the operator's MPLS domain towards the 
customer domain, the following functions are not mandatory:

- Flow classifier
- Packet classifier
- Classification policy
- Indirect mapping
- Direct mapping
- Flow policing

The partitioning of the edge functionality is dependent on the services 
offered to the customer, and who is responsible for performing the 
traffic classification.

The services that can be offered to customer by the public MPLS domain 
operator are:

- Best effort services 
- Differentiated services 
- Guaranteed services 
- MPLS 

The network boundary between the user's and operators network can 
support any number of the above services. Depending on the 
implementation model, the support for some of these services may 
require signalling support between the MPLS domain and subscriber 
interface.

The different cases are described in more detail in the following 
sections, from the operator border node's functionality standpoint.

9.2.2.1 Best effort services to customer

If the best effort service is provided to the customer, edge node would 
just map the traffic onto suitable LSP, according to procedures defined 
for best effort traffic in the [Callon97] and [Rosen97a].

If there are service guarantees (e.g. bandwidth) for the some portion 
of the user's traffic (e.g. for all traffic destined to network x), 
these can be honoured by applying the suitable filter to the traffic 
and assigning it to the designated LSP.

9.2.2.2 Differentiated services to customer

In the differentiated service model, the packets need to be marked on 
basis of some policy, and the packets receive the different treatment 
on basis of the values carried in the DS byte (encapsulated on TOS 



P.Vaananen, R. Ravikanth                                       [Page 42]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


field of IPv4 packet). This labelling can be performed by the customer 
equipment, such as CPE router or customer's hosts. 

In the case that the marking is performed by the subscriber, the 
operator's border router needs to police the traffic according to the 
service contract between the operator and the customer. Operator may 
also need to measure the traffic for accounting purposes, depending on 
the contract. 

Another alternative is that the operator performs this marking on the 
basis of the policy agreed with the customer in the access nodes. 

9.2.2.3 Guaranteed services to customer

For security reasons stated in the next chapter, the use of the 
guaranteed services towards the customer on based on the MPLS labelling 
is not advisable. 

If the guaranteed services are supported, the signalling protocol, such 
as RSVP needs to be terminated on the operator's border node and the 
filter to achieve the classification needs to be applied to each 
packet.

If signalling based guaranteed services is used towards the public 
network, the network operator may assign the resulting traffic onto 
it's own LSP or aggregate it to the LSP with suitable service 
guarantees towards the public network. Note that the operator's border 
router does not necessarily have to perform the aggregation, as it may 
be unlikely that there will be the suitable LSP towards the destination 
available. 

Alternatively, if signalling is not used, operator can just apply the 
set of pre-specified filters according to some policy agreed between 
the customer and the operator.

9.2.2.4 MPLS to customer

Operator can run MPLS towards the customer premises, but there are some 
important considerations that need to be taken in the account on such 
environments.

Since the customer is a non-trusted entity from the operator's 
standpoint, and the MPLS allows the establishment of the switched paths 
towards the destination, there is no possible way for the operator to 
control what enters onto LSP the subscriber's traffic enters onto. This 
opens the possibility of denial of service attacks, and other kinds of 
malicious uses that could possibly be prevented by the ingress 
filtering on the operator's ingress node. When the traffic enters on 
the LSP, it is impossible to determine where the traffic originated 
from after it is merged with the other traffic, assuming that the bogus 



P.Vaananen, R. Ravikanth                                       [Page 43]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


source addresses are used. The only way to prevent this would be to 
terminate the LSPs originated from customer premises on the operator's 
border node, but in such case there is no reason to run MPLS to the 
customer for this type of traffic at all. 

Additionally, as the customer does not have the information of the 
operator's traffic aggregation policies and access to the routing 
information, customer will not be able to perform traffic aggregation. 
This would, in practice, mean that the MPLS sessions between operator 
and subscriber would have to be based on individual flows, and operator 
would be responsible for appropriate aggregation. 

An environment, where the use of the MPLS to customer premises makes 
sense is when the MPLS is used to create VPNs for the customer. The 
customer could then assign the traffic that is destined on the LSP 
that's part of the VPN to appropriate VPN. Even in these environments, 
it would make sense to use ordinary routing for other traffic. This 
assumes that the VPN LSP endpoint(s) trusts the sending entity to some 
extent, as the traffic would be carried quite transparently through the 
operator's network.

In any case, all traffic that is entering onto operator's network that 
is destined to public the network should be validated for the source 
address before encapsulating to any label switched path.

So, as a summary, MPLS to the customer's premises does not make much 
sense in typical environments.

9.2.3 MPLS core node
 

Figure 9.2.3 Implementation framework for MPLS core node TM 
functionality 

MPLS core nodes are high capacity switching elements, that contain only 
MPLS interfaces.

Core nodes need to forward packets at high speed and differentiate the 
queuing treatment on basis of the label they are received with. These 
nodes also participate in routing and label distribution protocols, and 
have to support admission control for the traffic that has reservation 
requests.

The important thing to note is that the associated state information 
for the treatment of the arriving packets can be determined on basis of 
label, there is no need for the knowledge or reapplication of the 
admission policies or traffic filtering.

The following is a list of the traffic management functions typically 
performed by core node:



P.Vaananen, R. Ravikanth                                       [Page 44]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



Mandatory functions:

- Admission policy 
- Admission control 
- Aggregation 
- Queue management 
- Passive congestion control 
- Queuing
- Scheduling
- Label distribution

Optional mechanisms:

- Deaggregation
- Congestion marking
- LSP policing 

Above mechanisms are described in more detail in sections 5 and 6 of 
this document.


9.3 Interface categories
9.3.1 Interface to non-MPLS networks

This interface is the point where the MPLS domain connects to existing 
network infrastructure, and the first point in the ingress direction, 
where packet labelling is performed. Also, in the egress side of the 
interface, labels are removed and packets are encapsulated according to 
the corresponding data link layer encapsulation.

9.3.2 Interface inside MPLS network domains

This interface is the interconnection point between the different MPLS 
network elements inside the domain. This is characterised by the fact 
that the packets are received and transmitted labelled, and the 
forwarding and scheduling decisions are performed on basis of the label 
associated with the received packet.

9.3.3 Interface between MPLS network domains

This interface is the interconnection point between two operationally 
different MPLS network domains. 

Such an interface applies the policies related to admission of the 
labelled path set-ups through the operator's network, and meters the 
usage, especially for advanced service categories to be able to monitor 
/ create inter-operator settlement agreements. The policing functions 
in this interface are applied at the LSP level.




P.Vaananen, R. Ravikanth                                       [Page 45]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


The deaggregation of the arriving traffic aggregated to incoming LSPs 
to determine the appropriate LSPs inside domain traffic can be done 
either immediately on this interface point, or somewhere else in the 
network. This is generally required, as it is advantageous for the 
external domain's operator to aggregate the traffic as much as 
possible, and also since the internal topology (and corresponding LDP 
paths) is not known to external domain.

 
10. LSP MAPPINGS TO EXISTING LINK LAYER TECHNOLOGIES

The discussion of the mappings of the traffic of different service 
guarantees to specific data link layers, and what of the requirements 
outlined in chapter 4 can be achieved goes here. 

Concentrate on ATM and Frame Relay environments, and what is missing 
from the current best effort mapping proposals.

--- This section to be added later ---


11. GENERAL REQUIREMENTS FOR LABEL ENCAPSULATIONS
11.1 Differentiated services support

Proposals for the "differentiated services", require some priority 
bits to be carried in the packets to be used for providing additional 
information to help to select appropriate queuing and scheduling 
actions in the intermediate routers. These mechanisms generally rely on 
the use of the IPv4 TOS field.

At first look, it appears that the making the determination for the 
scheduling action should be based on both label and these 
differentiated service bits. There are however some reasons, which make 
the determination of all associated parameters strictly on basis of the 
information contained in the label:

1.) Straightforward mapping to hardware implementation

Since it is expected that the MPLS nodes may be based on the high-
capacity hardware implementation of the forwarding process, it is 
expected that the lookup result can directly be mapped onto hardware 
implementation of the particular product. Since the internal 
implementations of the supporting mechanisms are not subject to 
standardisation, it may be possible that even if the some header bits 
are used to indicate e.g. priority, some, possibly complex mapping 
needs to be performed to resolve the appropriate information to control 
HW based scheduling decisions. When the information is distributed with 
the LDP, the network element can perform necessary internal mappings, 
and then use the HW lookup table for determining the associated 
parameters that control scheduling hardware. 



P.Vaananen, R. Ravikanth                                       [Page 46]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



2.) Support for fine grained service guarantees

For the support of the fine grained service guarantees, such as INTSERV 
controlled load or guaranteed service, it is impractical to carry the 
required amount of the state information in every packet. Also, because 
implementations vary, the information cannot be subject to 
standardisation. In addition, reasons given in 1.) also apply here.

3.) Requires MPLS node to look only onto fixed portion of the header

Even if the information for the providing the differential services 
could be carried in the packet, the system becomes specific for the 
header formats of the given protocol, such as IPv4. When  the protocol 
is changed, the position where the information resides inside the 
header changes also. This implies that the hardware should be either 
able to identify the protocol on the fly to determine where to look for 
information, or this be statically configured for the entity doing the 
lookup function, which means that the simultaneous support of multiple 
protocols is not feasible. When the information is retrieved just on 
basis of label, these problems do not exist. It would be possible e.g. 
provide exactly same services for the IPv4 and IPv6 without any 
problems using the same label based forwarding entity.

4.)  Legacy HW support

Since much of the effort is currently concentrated on how the label 
switching should be supported in the legacy hardware with as little 
modifications as possible, it would make more sense to use the mapping 
on basis of the label. For example in ATM current ATM environments, 
there is no support for the differentiated services concept as being 
discussed, but there are some quite straightforward mappings that can 
be realised by using the currently defined ATM service categories.

5.) Single, standard forwarding paradigm

If the lookup is kept strictly as label only based, it means that same 
kinds of services can be provided for completely different applications 
and protocols using same network elements. Also, this means that the 
new services can be introduced by developing extensions to the LDP, and 
implementing the appropriate improvements in the network elements by 
keeping the same basic concept intact.

Note that the using different labels for different service class 
encodings increases the required label space, but on the environments 
that support only best effort or guaranteed traffic, these bits can be 
used by different LSPs.

11.2 Congestion management support

11.2.1 Congestion indicator bit


P.Vaananen, R. Ravikanth                                       [Page 47]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


For the purposes of the congestion management, it is desirable to have 
one bit of the label to indicate that the LSP is experiencing 
congestion.

If the label encapsulation header is protected by checksum that goes 
over the label, it is desirable that this bit is excluded from the 
checksum calculation so that the hardware can modify the bit directly, 
or that the checksum modification mechanism is specified that allows 
easy recalculation of the checksum when the bit is modified.

In the frame relay environments, FECN and BECN bits shall be used for 
the congestion notification bits. In ATM environments the CI bit of the 
header shall be used for congestion notification.

When the multilevel labelling is used, the value of the CI bit shall be 
copied to CI bit of second level label in deaggregation point, where 
the top level label is removed.

11.2.2 Examine me bit
For the more advanced traffic management mechanism support, it may be 
useful to have one bit of the label to indicate that the packet carries 
information that intermediate network element need either copy or 
modify. 

The advantage of having this bit encoded in the label instead than 
using dedicated LSP between nodes is that the associated operations can 
be made on per LSP basis, possibly in the hardware. 

The requirement for the support of this bit requires further study. It 
may be advisable to reserve one bit for this (or other) purposes from 
the beginning, even if the use has not been defined.

This cannot be easily supported in standard ATM switching hardware, but 
ATM provides similar mechanisms in cell level with OAM and RM cells.

11.3 Support for multilevel label switched paths

The multilevel label support is essential for the purposes of scaleable 
support of the label switched paths with explicit guarantees. The 
mechanisms for supporting this shall be included in the label 
encapsulation protocol.

Two levels of the multi-level labels are generally sufficient for the 
traffic management purposes and in ATM environments this may be 
realised using VPI/VCI partitioning to support first and second level 
label encodings.

12. GENERAL REQUIREMENTS FOR DISTRIBUTION OF LABELS AND TM ATTRIBUTES

To be able to realise the basic set of TM functionality, the following 



P.Vaananen, R. Ravikanth                                       [Page 48]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


functions shall be available in the protocol used to distribute labels 
and the associated traffic management attributes.

12.1 Setup request

This function is used to request the set up of the label switched path 
of desired topological scope, granularity and attributes. The traffic 
management related attributes need to be specified and available in the 
LSP set-up request.

Some of the traffic management related attributes that shall be 
available for set-up request function:

- Bandwidth (bits/s)
- Discard priority class (1-Ndisc)  (as specified by differentiated 
services WG)
- Delay priority class (1-Ndel) (as specified by differentiated 
services WG)

It shall be possible to add other possible attributes that may be 
required, depending on the desired services and/or signalling protocols 
that are to be used in MPLS context. 

12.2 Setup modification

LSP set-up modification function will be used to modify the attributes 
of the LSPs that have already been set up. Modification can be, e.g. 
addition or reduction of the bandwidth of the associated label switched 
path.

Same attributes as for the set-up request shall be available for set-up 
modification function.

12.3 Setup Acknowledge

LSP set-up acknowledge is received when the LSP with desired attributes 
has been set up. Set-up acknowledge can result of either set-up request 
or set-up modification functions.

12.4 Setup reject

LSP set-up is rejected when the LSP with desired attributes can not be 
supported by the network. Set-up reject can result of either set-up 
request or set-up modification functions. Set-up reject shall 
communicate the reason why the request or modification was rejected. 

Traffic management related parameters that shall be returned in error 
conditions that shall be available:

- Reason for rejection: no support for service, no LDP available, no 



P.Vaananen, R. Ravikanth                                       [Page 49]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


resources
- Information, such as: available bandwidth, highest available 
priority, etc.

12.5 Discussion of signaling protocols

12.5.1 General

There have been proposals to use RSVP for implementing all services 
that require more than best effort traffic category support in MPLS 
environment. 

Also, there is other proposal for implementing limited set of services 
for supporting limited set of traffic management functionality, mainly 
suitable for the network operator's traffic engineering  needs in the 
LDP protocol, which does not require the use of the LDP.

The approaches have similar characteristics, and it is quite possible 
to achieve the desired functionality in either way. Either method is 
not obviously better than the other, and it is unclear whether these 
proposals are complementary or competitive.

In addition, operator driven network traffic engineering purposes does 
not have as strict requirements for the dynamics and the granularity of 
control required. It might be feasible to implement the attributes 
required for the traffic engineered LSPs directly in the LDP, without 
mandating the use of the RSVP in networks that do not support 
differentiated services.

To determine the suitability of the signalling mechanisms for TM 
support the proposals should be evaluated and decided against the 
requirements for supporting the traffic management related requirements 
and their applicability to different topologies, topological scopes and 
reservation models.

12.5.2 LDP

Label Distribution Protocol (LDP) has been proposed for the 
communication of the bindings between the routes and the LSPs between 
the MPLS nodes. 

Current proposal of the LDP [Andersson97] does not include objects to 
carry any traffic management related attributes for the LSPs, except 
the placeholder for the Class-of-service objects. 

COS object semantics have not been specified in the current version of 
the document, and them will likely be based on the work done in the 
IETF DIFFSERV working group.

It has been proposed to extend the current LDP proposal to include the 



P.Vaananen, R. Ravikanth                                       [Page 50]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


basic set of the traffic management related attributes as part of the 
LDP. Reasoning behind this is that in the environments that are not 
otherwise using the RSVP, and do not need all the features provided by 
RSVP, the additional complexity inherited with the RSVP may be too 
expensive to implement, and the use of single protocol (LDP) should be 
sufficient.


12.5.3 RSVP

RSVP [RFC2205] was originally developed for the establishment of the 
communication of the reservation parameters of the unicast traffic and 
reservation parameters for heterogeneous receivers for the multicast 
traffic. 

RSVP has scalability issues for the large scale deployment, that are 
discussed in the [RFC2208] and [Schwantag97].

MPLS can be used to address some of the scalability problems of the 
RSVP, by using the RSVP signalling at the edges of the network and 
either RSVP tunnels inside networks, or by mapping the reservations to 
some other signalling protocol, used to carry reservation information 
inside the operator's network and possible across domain boundaries.

MPLS networks have the ability, in the core network elements, to make 
forwarding decisions using simple label based lookup instead of 
applying the flow specific filter to each packet, as required by the 
conventional RSVP implementation. Also, because of the aggregation of 
the reservations, the core routers can forward the traffic without 
keeping track of per-flow state.

MPLS has also been proposed as signalling protocol to be used in MPLS 
context for communicating the reservation attributes of the label 
switched paths inside the network [Li97]. This operation model can be 
coupled to user-to-network RSVP signalling, or operate independently 
inside the network, between the network elements.

There are also proposals for setting up explicit paths with 
reservations inside MPLS domain using extended RSVP and assigning 
labels for such paths [Gan97], [Guerin97] [Davie97a] and [Davie97b].

13. REFERENCES

[Andersson97] "LDP Specification", L. Andersson, P. Doolan, N. 
Feldman, Andre Fredette, work in progress, draft-mplsdt-ldp-spec-
00.txt, November 1997

[ATMF96], "Traffic Management Specification, Version 4.0", ATM Forum, 
April 1996 




P.Vaananen, R. Ravikanth                                       [Page 51]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


 [Berson97] "Aggregation of Integrated Services State", S. Berson, S. 
Vincent, work in progress, draft-berson-classy-approach-01.ps, November 
1997

[Braden97] "Recommendations on Queue Management and Congestion 
Avoidance in the Internet", B. Braden, D. Clarck, J. Crowcroft, B. 
Davie, S. Deering, D. Esterin, S. Floyd, V. Jacobson, G. Minshall, G. 
Partridge, L. Pettersson, K. Ramakrishnan, S. Schenker, J. Wroclawski 
and L. Zang, work in progress, draft-irtf-e2e-queue-mgt-00.ps, March 
1997

[Bradner97] "Internet Protocol Quality of Service Problem Statement", 
S. Bradner, work in progress, draft-bradner-qos-problem-00.txt, 
September 1997
 
[Callon97] "A Framework for Multiprotocol Label Switching", R. 
Callon,P. Doolan, N. Feldman, A. Fredette, G. Swallow, and A. 
Wiswanathan, work in progress, draft-ietf-mpls-framework-02.txt, 
November 19, 1997

[Claffy95] "A parameterizable methodology for Internet traffic flow 
profiling", K.C. Claffy, H-W. Braun, G. C. Polyzos, IEEE Journal on 
Selected Areas in Communications, vol. 13, no. 8, pp. 1481-1494, 
October 1995.

[Cisco97] "Netflow", White Paper, Cisco Systems, 1997

[Crawley98] "A Framework for QoS-based Routing in the Internet", E. 
Crawley, R. Nair,B. Rajagopalan , H. Sandick, work in progress, draft-
ietf-qosr-framework-03.txt,                March, 2, 1998
                                                
[Davie97a]	"Use of Label Switching With RSVP ", B. Davie, Y. 
Rekhter, E. Rosen, A. Viswanathan, V. Srinivasan, work in progress, 
draft-davie-mpls-rsvp-01.txt, November 1997

[Davie97b] "Explicit Route Support in MPLS", B. Davie, T. Li, E. 
Rosen, Y. Rekhter,work in progress, draft-davie-mpls-explicit-routes-
00.txt, November 1997

[Ferguson98] "Simple Differential Services: IP TOS and Precedence, 
Delay Indication, and Drop Preference", P. Ferguson, work in progress, 
draft-ferguson-delay-drop-01.txt, March 10, 1998

[Floyd93] "Random Early Detection gateways for Congestion Avoidance", 
S. Floyd, V. Jacobsen, IEEE/ACM Transactions on Networking, volume 1 
number 4, August 1993, Pages 397-413

[Fredette97] "Stream Aggregation", A. Fredette, C. White, L. 
Andersson, P. Doolan , work in progress, , November 1997



P.Vaananen, R. Ravikanth                                       [Page 52]

Internet-Draft  Framework for TM in MPLS Networks             March 1998



[Gan97] "Setting up Reservations on Explicit Paths using RSVP", D.-H. 
Gan, R. Guerin, S. Kamat, T. Li, E. Rosen, work in progress, draft-
guerin-expl-path-rsvp-01.txt, 21 November 1997

[Guerin97] "Aggregating RSVP-based QoS Requests" R. Guerin, S. Blake, 
S. Herzog, work in progress, draft-guerin-aggreg-rsvp-00.txt, 21 Nov 
1997

[I370] "Congestion Management for the ISDN Frame Relaying Bearer 
Service", Recommendation  I.370, ITU-T, 1991
 
[Jagan97] "End-to-End Traffic Management in IP/ATM Internetworks", S. 
Jagannath, N. Yin, work in progress, draft-jagan-e2e-traf-mgmt-00.txt, 
August 1997

[Li98] "Provider Architecture for Differentiated Services and Traffic 
Engineering (PASTE)", T. Li, Y. Rekhter, work in progress, draft-li-
paste-00.txt, January 1998

[Nichols98] "Differentiated Services Operational Model and 
Definitions", K. Nichols, S. Blake, work in progress, draft-nichols-
dsopdef-00.txt, February, 1998

[Packeteer97] "Controlling TCP/IP bandwidth", TCP/IP bandwidth 
Management Series, Vol 1 Number 1, The Packeteer technical Journal, 
1997

[Ramakr97] "A Proposal to add Explicit Congestion Notification (ECN) 
to IPv6 and to TCP", K. K. Ramakrishnan, S. Floyd, work in progress, 
draft-kksjf-ecn-00.txt,                                                     
November 1997
 
[Rampal97] "Flow Grouping For Reducing Reservation Requirements for 
Guaranteed Delay Service",S. Rampal, R. Guerin, work in progress, 
draft-rampal-flow-delay-service-01.txt, July 15th, 1997.

[RFC1633] "Integrated Services in the Internet Architecture: an 
Overview", R. Braden, D. Clarck, S. Shenker, RFC-1633, June 1994

[RFC1827] "IP Encapsulating Security Payload (ESP)", R. Atkinson, 
RFC-1827, August 1995

[RFC1954] "Transmission of Flow Labelled IPv4 on ATM Data Links", P. 
Newman, W. L. Edwards, R. Hinden, E. Hoffman, F. Ching Liaw, T. Lyon, 
G. Minshall, ,RFC-1954, May 1996

[RFC2063] "Traffic Flow Measurement:  Architecture", N. Brownlee, C. 
Mills, G. Ruth, RFC-2063, January 1997




P.Vaananen, R. Ravikanth                                       [Page 53]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


[RFC2205] "Resource Reservation Protocol (RSVP) - Version 1 Functional 
Specification", R. Braden, L. Zhang, S. Berson, S. Herzog, S. Jamin, 
RFC-2205, September 1997

[RFC2208] "Resource ReSerVation Protocol (RSVP) Version 1 
Applicability Statement: Some Guidelines on Deployment", A. Mankin, F. 
Baker, B. Braden, S. Bradner, M. O`Dell, A. Romanow, A. Weinrib, L. 
Zhang, September 1997

[RFC2211] "Specification of the Controlled-Load Network Element 
Service", J. Wroclawski, RFC-2211, September 1997

[RFC2212] "Specification of the Guaranteed-Quality of Service", S. 
Shenker, C. Partridge, R. Guerin, RFC-2212, September 1997
 
[Rosen97a] " A proposed architecture for MPLS", E. Rosen, A. 
Wiswanathan and R. Callon, work in progress, draft-ietf-mpls-arch-
00.txt, July 1997

[Rosen97b] "Label Switching: Label Stack Encodings", E.C. Rosen,Y. 
Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T. Li, A. Conta, work in 
progress, draft-rosen-tag-stack-03.txt, July 1997

[Schwantag97] "An Analysis of the Applicability of RSVP", Ursula 
Schwantag, Diploma Thesis, Universitat Karlsruhe, July 15, 1997

[Smith97] "Research Challenges for the Next Generation Internet", 
J.E. Smith, F. W. Weingarten, Computing Research Association, May 12-
14, 1997

[Tennenh89] "Layered Multiplexing Considered Harmful", D. 
Tennenhouse, Protocols for High-Speed Networks, Rudin and Williamson 
(Editors), North Holland, Amsterdam, 1989. 
 
[Touch97] "Bridging the Gap Between Optical Networks and the Internet: 
Summary of a Mini-Workshop", DRAFT, Oct. 1-2, 1997, Arlington, VA, Joe 
Touch,  Ken Young, Joe Berthold

14. SECURITY CONSIDERATIONS

As the support for the different levels of services, together with the 
different pricing structures comes in the effect, the mechanisms to 
monitor the service usage, enforce the service contract between 
parties, authorisation and billing will become important.

It is essential to develop the associated protocols in a such way, that 
the different forms of service abuse, such as different forms of theft 
of service are not easily possible.

Since this document is not protocol specification, the specifics of the 



P.Vaananen, R. Ravikanth                                       [Page 54]

Internet-Draft  Framework for TM in MPLS Networks             March 1998


implementation alternatives are not discussed here.

15. AUTHOR'S ADDRESSES

Pasi Vaananen
Nokia Telecommunications, Inc.
3 Burlington Woods Drive, Suite 250
Burlington, MA 01803
USA
Phone: (781) 238-4981
Fax: (781) 238-4949
Email: pasi.vaananen@ntc.nokia.com

Rayadurgam Ravikanth
Nokia Research Center
3 Burlington Woods Drive, Suite 260
Burlington, MA 01803
USA
Phone: (781) 238-4905
Fax (781) 238-4949
Email: ravikanth.rayadurgam@research.nokia.com
































P.Vaananen, R. Ravikanth                                       [Page 55]