PPP Working Group Mooi C. Chuah
Internet Draft Enrique J. Hernandez-Valencia
Expires December 1999 Lucent Technologies Bell Laboratories
Matt Holdrege
Ascend Communications
June 1999
QoS Mapping Extensions to Multilink PPP
<draft-ietf-pppext-mp-qos-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is the product of the Point-to-Point Protocol
Extensions Working Group of the Internet Engineering Task Force
(IETF). Comments should be submitted to the ietf-ppp@merit.edu
mailing list.
Distribution of this memo is unlimited.
Abstract
This document discusses QoS mapping extensions to multilink PPP. The
extensions facilitate the mapping of particular flows to a given
physical link and with a given PPP class. The extensions are intended
to provide more flexible quality of service support for wireless
networking environments.
This document is the product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments should
be submitted to the ietf-ppp@merit.edu mailing list.
Chuah, et al. expires December 1999 [Page 1]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
Applicability
These extensions are intended for those implementations which desire
to use the multilink PPP capability but also need to allocate
specific flows to a given physical link.
Table of Contents
1. Introduction ............................................... 3
2. Design Requirements ........................................ 6
2.1. Non-Sharing QoS (NS-QoS) Option .......................... 8
2.2. QoS-Map Multilink Header Format (QoS-MMHF) Option ........ 9
3. Formats of the LCP Options ................................. 9
3.1. Non-Sharing QoS Option ................................... 9
3.2. QoS-Map Multilink Header Format (QoS-MMHF) Option ........ 10
4. Security Considerations .................................... 11
5. References ................................................. 11
6. Intellectual Property Considerations ....................... 12
7. Acknowledgements ........................................... 12
8. Authors' Addresses ......................................... 12
Chuah, et al. expires December 1999 [Page 2]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
1. Introduction
In many networking scenarios, such as in wireless networks, there are
capabilities defined to instantiate multiple physical links with
difference performance characteristics between two peers. To make
better use of QoS capabilities implemented by various link and net-
work layer protocols there is a need to map QoS indications from one
layer to the other. Below is an example specific to wireless net-
works.
Foreign | Home
AAA | AAA
^ | ^
IFA2 | | |
V V
MN ---- BS1 --IWF(IFA1) --- VPDSN ----- HPDSN ----- HA
(GFA) (GHA)
MN: Mobile Node
BS: Base Station
IWF: Interworking Function
IFA: Intermediate Foreign Agent
GHA: Gateway Home Agent
GFA: Gateway Foreign Agent
HPDSN: Home Packet Data Service Node
VPDSN: Visiting Packet Data Service Node
AAA: Authentication, Authorization, Accounting Server
Figure 1: Generic Wide Area Data Network Reference Model
Figure 1 shows a generic wide area wireless data network reference
model. In the most general scenario of interest the MN is assumed to
request IP services from a foreign wireless network other than its
home service provider. Support of mobile-IP services [10] typically
requires that messages are "tunneled" from the home IP network to the
foreign IP network for addressing and routing purposes.
The interworking functions (IWF) terminates the radio link. It is also assumed that different IWFs can communicate with one another. The communication between the Base Station (BS) and the IWF can be either by means of link-layer or network-layer messages. In this document it is assumed
communications is by means of link-layer messages.
The protocol stack for supporting regular IP services in a typical
Chuah, et al. expires December 1999 [Page 3]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
wide area wireless access network is as shown in Figure 2. The
current working model in Telecommunications Industry Association's
(TIA) TR45.6 WG [4][5] uses PPP as the link-layer between the Termi-
nal Equipment/Mobile Terminal (TE/MT) and the visiting Packet Data
Service Node (PDSN). The PDSN functions are typically implemented in
packet switches or routers. The MN first registers with the closest
BS via link-layer messages. Then, a PPP session is activated between
the MN and the visiting PDSN. Via the PPP session set up procedures,
the Visiting PDSN can assign an IP address dynamically to the TE/MT.
In addition, some layer 3 tunnel set up messages will be exchanged
between the visiting and the home PDSNs such that a core IP tunnel
will exist from the home PDSN to the visiting PDSN. This tunnel will
be used to deliver packets destined for the MN. If necessary, a
reverse tunnel will be set up from the visiting PDSN to the home PDSN
to deliver traffic from the MN to any host within the home network.
Packets destined to the mobile user can be intercepted by the home
PDSN and delivered to the visiting PDSN via the core IP tunnel. The
visiting PDSN in turns delivers them to the appropriate IWF via the
backhaul IP tunnel if the network between the visiting PDSN and IWF
is an IP network. Note that, this backhaul IP tunnel is intended to
carry PPP frames. Either L2TP [9] or an enhanced version of the tun-
nel establishment protocol [6] may be used to set up this backhaul IP
tunnel. The IWF will then forward the packets to the appropriate base
station, which then delivers them to the mobile node. Packets from
the mobile node will similarly be delivered from the base station to
the IWF, which forwards them to the visiting PDSN. If no reverse tun-
nel exists, the packets will be forwarded to the home PDSN via regu-
lar IP routing (only if packets are destined for a host within the
home PDSN). Otherwise, the traffic will be carried by the reverse
core IP tunnel between the visiting PDSN and the home PDSN.
----- ----------- ---------
|IP | | IP | | IP |
----- ----------- ---------
|PPP| |PPP | | | |
----- ---------- ------ | | |
|L/M| |L/M|BHIP| |BHIP|TIP | | TIP |
| | | | L2 | |L2 | L2 | | L2 |
----- ---------- ----------- ---------
|WL | ----- |WL | L1 | ---- | L1 | L1 | -///- | L1 |
----- --------- ----------- ---------
TE/MT IWF V-PDSN H-PDSN
TE/MT: Terminal Equipment/Mobile Terminal
L/M: LAC/MAC
WL: Wireless Physical Link
BHIP: Backhaul IP tunnel
TIP: Core IP tunnel
Chuah, et al. expires December 1999 [Page 4]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
L2: Layer 2 (Link Layer)
L2: Layer 1 (Physical Link)
H-PDSN: Home PDSNV-PDSN: Visiting PDSN
Figure 2: Using Existing Standard with PPP as link-layer
For future wireless data services, the ability to provide quality of
service features is critical as more multimedia web-based applica-
tions like PointCast or Netmeeting become popular. Thus, enhancing
the PPP protocol to support quality of services is a very attractive
option. There are existing proposals on how to provide quality of
service features at the PPP layer, e.g., real-time framing [1], mul-
ticlass extensions to multilink PPP [2] as well as define service
mappings of the IETF Integrated Services for low-bitrate links [8].
However, these proposals do not address some important needs that
arise in 3G wireless systems. Real-time framing [1] proposal is not
sufficient to meet the needs of wireless data services because the
PPP peers can only become aware of the different traffic classes
instantiated when bearer traffic appears in the receiving interfaces.
In wireless access networks, there is a need to know the class number
values ahead of time to decide which type of wireless links to
activate. Multiple PPP/RTF links would not be appropriate since they
would be handled as independent links (with a separate IP address per
physical link). Multiclass extension to multilink PPP [2] are not
well-suited to TR45.6 environments due to various reasons. Among oth-
ers:
(a) In 3G wireless systems, a mobile user has the flexibility of
activating multiple wireless links with different quality of service
characteristics, e.g., one link that supports voice with no link
layer retransmission, one link that supports data with link layer
retransmission and another link that supports video with higher
bandwidth and forward error correction. Although the multiclass
extension proposal increases the number of traffic classes that may
be defined over the point-to-point link, multilink PPP also bundles
the separate physical point-to-point links between two entities into
a single virtual link. Yet, it is not always appropriate to dissect
one video packet into multiple multilink PPP fragments to send them
across the multiple wireless links. For example, some of the wireless
links may not be engineered to carry video fragments. What is desir-
able is to have the ability to map packets from one or multiple IP
sessions into one of the wireless link in the link bundle.
Chuah, et al. expires December 1999 [Page 5]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
(b) The multilink header option in [3] only specifies the maximum
number of classes for a multilink PPP session. It does not specify
exactly what those classes are. It will be desirable to know ahead of
time the exact class numbers that are activated at any particular
time for admission control, radio resource management, and traffic
engineering purposes.
(c) In most standard multilink PPP implementations, each packet is
fragmented and sent across multiple links. In a cellular environ-
ment, a mechanism is needed to allow packets from some given ses-
sions to be sent to one physical link and packets from other sessions
to be sent to another physical link.
In the service mapping draft [8], only guidelines on how to map pack-
ets into multiple PPP Quality of Service classes are given. Again,
the PPP peer cannot know the class numbers or types until it receives
the bearer traffic. The draft also does not mention how to map different PPP QoS classes into different wireless links.
In this document, two LCP options are defined to allow communicating
interfaces to:
a) send packets of a particular class number to a particular link in
a link bundle b) provide upfront information on the specific classes
to be supported rather than wait until packets of that class appear.
The defined LCP options can work with Real-Time Framing [1],
Multiclass-Multilink PPP [2] as well as the service mapping [8]
drafts for can use either the real-time framing format or the
multiclass-multilink PPP format for the bearer traffic.
2. Design Requirements
The main design requirements are: (i) to provide a mechanism such
that real-time multimedia flows can be carried over multiple PPP
links (which translates to multiple wireless links of different
characteristics), and (ii) to achieve quality of service requirements
for each of the PPP links, (iii) consistency with existing PPP LCP
functionality.
In this document, two new PPP LCP options are defined to achieve the
requirements described above. There are several more detailed
requirements for the defined QoS mechanism:
a) the scheme must be predictable enough that admission control can
be made during the PPP negotiation phase.
Since radio resources are often limited, a new session will be
Chuah, et al. expires December 1999 [Page 6]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
admitted only when enough resources can be allocated to meet its
quality of service requirements. In order to make this decision, the
system needs to know the exact types of the different classes that
will be activated over any specific link. Multilink approaches (such
as Multilink PPP [3]) are more suitable than single link approaches
(such as conventional PPP) for supporting multimedia services due to
the following reason: A user may buy both voice-over-IP and regular
internet access services. When a user activates a PPP session at
timet t1, he/she may just want to activate the regular internet
access (mostly web-browsing) service. This service may use, for
instance, the highest class number (which denotes the lowest prior-
ity treatment) for best effort service. Half-way through the
activated PPP session, he/she may wish to add in the voice-over-ip
service. The voice-over-IP service may be supported via the lowest
class number (which denotes the highest priority treatment). If there
exists sufficient resources, the voice service can be better sup-
ported over a second wireless link that is optimized for voice.
In 3G wireless system that supports multimedia services, radio
resource management and admission control are very critical. A user
may be granted 144 Kbps for conventional internet access service if
it is close to the base station and has a good radio link (very lit-
tle fading etc.) but only 9.6 Kbps if it is at the edge of a cell.
This may be sufficient to meet the user's need. However, when a user
wishes to activate a voice call, it desires to have a dedicated 9.6
Kbps in order to enjoy good voice quality. The network may decide to
reduce the bandwidth allocated to the data user from 144 Kbps to 56
Kbps in order to admit in a second voice user. Thus, knowing ahead of
time (before traffic packets are sent) what PPP QoS classes are using
any particular PPP link help the 3G wireless system to perform better
radio resource management.
b) the scheme must allow packets with a particular class number(s) to
be carried over a specified physical link.
Using the example illustrated in (a), one may use a wireless link
that does not support retransmissions to support the voice-over-IP
service and a wireless link with automatic retransmission request
(ARQ) to support the internet browsing service or other non-real time
services. Thus, it is highly desirable to send packets of a particu-
lar class number(s) via a chosen link (whose characteristics matches
the quality of service requirements for that class number(s)).
c) the scheme must be robust against errors
d) the scheme must in general interoperate with existing PPP func-
tionalities.
Chuah, et al. expires December 1999 [Page 7]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
Two new LCP options, namely the Non-Sharing QoS Negotiation option,
and the QoS-Map Multilink Header Format Option, are defined to
achieve the requirements described in section 2. Below are brief
descriptions of these options.
2.1. Non-Sharing QoS (NS-QoS) Option
During the LCP negotiation phase, the PPP peers can include the newly
defined Non-sharing QoS Option together with MRRU and End Point
Discriminator Options. The Non-sharing QoS Option allows one to
specify the number of classes to be carried on a particular link. Say
the PPP peers first activate a link (link 1) using this Non-Sharing
Qos Option and specifies that there will be 2 classes on link 1,
namely classes 3 and 4. Then, the PPP peers activate 2 more links
without enabling the Non-sharing QoS option. This means all PPP
frames with class numbers 3 and 4 will be carried over link 1, the
rest of the PPP frames will be segmented and carried over the two
remaining links that do not support the Non-sharing option. Note that
the bearer data (PPP frames) can use either the short or long
sequence number fragment format with classes. We recommend using
a different sequence number space for each physical link that
supports the Non-Sharing Option.
The PPP peers must have the understanding that if NS-QoS option is
negotiated, then the option applies for the traffic in both direc-
tion. Using the example in the earlier paragraph, it means PPP
frames with class numbers 3 and 4 will be carried over link 1 in
either direction.
Figure 3 illustrates how the Non-Sharing QOS Option is used with
standard Multilink PPP.
Cls 3, Cls4
A -----------> B
Cls 3, Cls4
<----------
Figure 3(a): Traffic on Link 1 between A-B with Non-Sharing Option
Cls2-Frag, Cls1-Frag
A -------------------> B
Cls2-Frag, Cls1-Frag
<------------------ B
Figure 3(b): Traffic on Link 2 between A-B without Non-Sharing Option
Chuah, et al. expires December 1999 [Page 8]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
Cls2-Frag, Cls1-Frag
A -------------------> B
Cls2-Frag, Cls1-Frag
<------------------ B
Figure 3(c): Traffic on Link 3 between A-B without Non-Sharing Option
2.2. QoS-Map Multilink Header Format (QoS-MMHF) Option
To support the mapping of differentiated services PHBs and other
Layer 3 fields to PPP QoS classes, another LCP option is defined:
QoS-Map multilink header format option.
Say both PPP peers carry IP packets with multiple DS-code points
(DSCP) [7] marked, namely DSCP Code 1, DSCP Code 2, DSCP Code 3 and
DSCP Code 4. Assume that there is the desire to map DSCP Code 1 and
DSCP Code 2 to PPP QoS Class 1 and DSCP Code 3 and DSCP Code 4 to PPP
QoS Class 2. The PPP peers use the Qos-EMHF Option to inform one
another of this mapping so that they can mark the PPP frames
appropriately. Without this option, both PPP peers may perform dif-
ferent mapping. Equipment from different vendors may not perform the
same mapping and hence it is harder to provide QoS guarantees over a
PPP/MP link.
3. Formats of the LCP Options
The formats of the two newly defined LCP options, namely the Non-
Sharing Qos option, and the Qos-Map multilink header format option
are described below.
3.1. Non-Sharing QoS Option
A summary of the Non-Sharing QoS Option format is shown in figure 4.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 5 | Code |NoCls | Rsv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS BitMap |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Non-Sharing QoS Option Format
Chuah, et al. expires December 1999 [Page 9]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
The values defined in this document for the use of this option are:
- Code = 2: long sequence number packet format with classes
- Code = 6: short sequence number packet format with classes
- Code = 11: basic and extended compact real-time fragment format
with classes, in FSE-encoded HDLC frame
- Code = 15: basic compact real-time fragment format with classes,
in FSE-encoded HDLC frame
It is assumed that 16 PPP QoS classes are sufficient (classes 0-15 with
0 as the highest priority class). Thus, a 2-bytes bitmap is used to
indicate the presence/absence of a particular class number. If the
PPP peers desire to communicate the idea that there will be 3 classes
on this link, namely cls 3, cls 4, and cls 5, then NoCls field will
be set to 3, and the the bitmap should be set as follows:
QoS BitMap Bytes
00011100 00000000
3.2. QoS-Map Multilink Header Format (QoS-MMHF) Option
A summary of the QoS-Map Multilink Header Format (QoS-MMHF) Option
format is shown in figure 5. The fields are transmitted from left to
right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD | Length = 7 |ClsNo|NoSD |Rsv| OptionTyp=1 |
| | | = 1 | = 3 | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP #1 | DSCP #2 | DSCP #3 |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ClsNo: PPP QoS Class Number
NoSD: No of session descriptor associated with this PPP QoS Class
Chuah, et al. expires December 1999 [Page 10]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
OptionTyp= 1: Session Descriptor is DSCP codepoint (1 byte)
Additional OptionTyps may also be define.
For example, as shown in the figure, one may define one PPP QoS No
say Class 1 with session descriptor being the DSCP code point
(OptionTyp=1) and map 3 DSCP code points to this PPP Class Number.
Wireless Service Option Number refers to the type of wireless link
that one may want to use for a particular PPP QoS class.
If the receiving PPP peer cannot accept this mapping, it MUST
Configure-Nak or Configure-Reject the option.
Implementations SHOULD provide sufficient buffer space to accommodate
different classes of services they provide each multilink PPP user
with.
4. Security Considerations
Many of the security issues raised by the introduction of quality of
service, and primarily the potential for denial-of- service attacks,
and the related potential for theft of service by unauthorized
traffic are also applicable to these options.
Beside the QoS-related security issues, this document introduces no
other known security threats over and above those facing any node on
the internet that connect via PPP.
5. References
[1] C. Bormann, "PPP in a real-time oriented HDLC-like framing",
ISSLL WG work in progress, <draft-ietf-issll-isslow-rtf-05.txt>,
April 1999.
[2] C. Bormann "The Multiclass Extension to Multilink PPP", PPPEXT
WG work in progress, <draft-ietf-issll-isslow-mcml-06.txt>,
June 1999.
Chuah, et al. expires December 1999 [Page 11]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
[3] K. Slower et al., "The PPP Multilink Protocol (MP)", RFC 1990,
August 1996.
[4] T. Hiller et al., "3G Wireless Data Provider Architecture Using
Mobile IP and AAA", <draft-hiller-3gwireless-00.txt>, March, 1999
[5] T. Hiller, "Wireless IP Network Architecture based on IETF
Protocols", TR45.6-3G/99.05.17.06.
[6] P. Calhoun et al., "Tunnel Establishment Protocol",
<draft-ietf-mobileip-calhoun-tep-01.txt>, March 1998.
[7] K. Nichols et al., "Definition of the differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[8] S. Jackowski et al., "Integrated Services Mappings for Low
Speed Networks", ISSLL WG work in progress
<draft-ietf-issll-isslow-svcmap-08.txt>, May 1999.
[9] W. Townsley et l., "Layer Two Tunnelling Protocol," PPPEXT WG
work in progress, <draft-ietf-pppext-l2tp-16.txt>. June 1999.
[10] C. Perkins, "IP Mobility Support", RFC 2002. October 1996.
6. Intellectual Property Considerations
Lucent Technologies Inc. may own intellectual property in some on
some of the technologies disclosed in this document. The patent
licensing policy of Lucent Technologies Inc. with respect to any
patents or patent applications relating to this submission is stated
in the March 1, 1999, letter to the IETF from Dr Roger E. Stricker,
Intellectual Property Vice President, Lucent Technologies, Inc. This
letter is on file in the offices of the IETF Secretariat.
7. Acknowledgements
The authors acknowledge useful comments from G. Armitage.
8. Authors' Addresses
Mooi C. Chuah
Bell Laboratories
Chuah, et al. expires December 1999 [Page 12]
INTERNET DRAFT MP QoS Mapping Extensions June 1999
Lucent Technologies
101, Crawfords Corner Road,
Holmdel, NJ 07733
chuah@bell-labs.com
(732)-949-7206
Enrique J. Hernandez-Valencia
Bell Laboratories
Lucent Technologies
101, Crawfords Corner Road,
Holmdel, NJ 07733
enrique@bell-labs.com
(732)-949-6153
Chuah, et al. expires December 1999 [Page 13]
