Network Working Group Jong-Moon Chung
Internet Draft (Oklahoma State University)
Expiration Date: August 2002 Kannan Srinivasan
(Oklahoma State University)
Mauricio A. Subieta Benito
(Oklahoma State University)
March 2002
Wireless Multiprotocol Label Switching (WMPLS)
draft-chung-mpls-wmpls-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.
Abstract
The framework of wireless multiprotocol label switching (WMPLS) technology in
applications of wireless mobile communications and ad hoc networking is presented
in this document. WMPLS has been designed to be a homogeneous protocol to MPLS as
well as Generalized MPLS (GMPLS) and MPLambdaS. The protocol format of WMPLS
closely resembles the original MPLS protocol architecture with wireless
communication reliability enhancements for end-to-end and hop-by-hop flow and
error control. This document provides the framework of WMPLS and its signaling
protocols (LDP and RSVP-TE) to establish connection-oriented and connectionless
label switched paths (LSPs). Operational procedures of WMPLS for soft handover in
mobile communications are provided. In addition, an example of WMPLS applied in an
overlay model with IMT-2000 is provided. This document also provides the technical
foundation of WMPLS applications in ad hoc and mobile ad hoc networks (MANETs).
Jong-Moon Chung, et al. Page <1>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
Table of Contents
1. Introduction...................................................2
2. WATM Limitations and Challenges................................3
3. WMPLS Label Format.............................................3
3. Extensions to the Signaling Protocols for WMPLS Operations.....5
3.1. Extensions to RSVP-TE for WMPLS................................5
3.1.1. Path Message Extensions Through The Label Request Object.......5
3.1.2. Resv Message Extensions Through The Label Object...............6
3.1.3. Hop Count and Sequence Number (HCSN) Object ...................6
3.2. Extensions to LDP for WMPLS....................................7
3.2.1. Wireless Label Request Message.................................7
3.2.2. Wireless Label Mapping Message.................................7
3.2.3. Extensions to the Label TLV....................................8
4. Handover in WMPLS Mobile Communication Networks................9
4.1. The Proposed Network Topology..................................9
4.1.1. Initial Path Setup............................................10
4.1. Path Establishment during Handover............................12
4.2. WMPLS Over IMT-2000...........................................13
5. WMPLS Mobile Ad Hoc Networking Support........................15
5.1. Ad Hoc and Mobile Ad Hoc Networks.............................15
5.1.1. Connection Types..............................................16
5.1.2. Node Mobility Types...........................................16
5.1.3. Traffic, QoS and Traffic Engineering Parameters...............16
5.1.4. Neighbor Discovery............................................16
5.1.5. Size and Bandwidth Utilization................................17
5.2. WMPLS Performance Considerations..............................17
5.3. WMPLS Ad Hoc Networking (WMPLS-AHN) Mechanisms................17
5.3.1. WMPLS-AHN within a MANET......................................18
5.3.1.1. Neighbor Discovery............................................18
5.3.1.2. Initial Route Calculation.....................................19
5.3.1.3. Route recalculations..........................................22
5.3.1.4. Route Tear-Down...............................................22
5.3.2. WMPLS between MANETs..........................................23
6. Conclusion....................................................24
7. References....................................................25
1. Introduction
The development of WMPLS technology has been focused on providing flexible levels
of traffic engineering (TE), quality of service (QoS), differentiated services
(DS), while supporting integrated services of real-time and non-real-time data.
The justification for creating WMPLS is based on four aspects. The first aspect is
focused on the fact that high quality broadband wireless data communications is in
strong demand, and in order to satisfy this growing demand for diverse services
and quality of data, the wireless communications network needs to become a
homogenous part of the backbone WAN. Then, the QoS and grade of services (GoS)
features requested of the WAN can be supported through the wireless network as
well. The second aspect is based on the fact that MPLS, GMPLS, and MPLambdaS
networks are currently under development for applications in future networks and
the wireless version of these technologies resulted in the development of WMPLS.
The third aspect is focused on the need of a protocol that can support end-to-end
and hop-by-hop connection-oriented or connectionless mobile communications, and
Jong-Moon Chung, et al. March 2002 Page <2>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
additionally ad hoc and mobile ad hoc wireless networking. The fourth aspect is
focused on the application of wireless differentiated services.
In the following section, the limitations and challenges of wireless ATM (WATM)
networking are presented to illustrate the improvements that WMPLS networking can
provide.
2. WATM Limitations and Challenges
Some of the limitations and challenges of ATM and WATM networks are summarized.
First, ATM and WATM networks do not support service differentiation of priority
data packages (i.e., differentiated services). Second, ATM and WATM do not specify
a sufficient flow/error control mechanism to enhance hop-by-hop reliability;
instead it relies on the upper or lower layer protocols to control ARQ reliability
services. Third, WATM is not suitable for connectionless or connection-oriented ad
hoc and mobile ad hoc wireless networking that require efficient data relay
functions. Fourth, WATM cells have a fixed payload size of 48 bytes where the type
of application specifies the payload ATM adaptation layer (AAL) segmentation and
reassembly (SAR) format. This puts a limit on the flexibility of applications
(payload coding for error control or encryption) to various wireless systems.
3. WMPLS Label Format
WMPLS applies three fundamental protocol header formats, which are shown below.
Within the WMPLS network, the first 2 bits of the 20-bit Label field will be read
as a Flag (F) field. This field will determine if a Control field and a cyclic
redundancy check (CRC) field are applied or not, and it will also indicate the
length of the applied Control field either being 1 or 2 bytes, corresponding to
the number of sequence bits used, either 3 or 7 bits, respectively. In an overlay
model, where the lower layer protocol provides error and flow control, the WMPLS
header format with no Control field and no CRC field can be used. To identify this
label format, the first two bits of the label will be set to zero, which will
imply that no control field and no CRC field are being used. In the Control field,
as shown below, N(S) is the sending sequence packet number and N(R) is the
automatic retransmission request (ARQ) or flow control acknowledging frame
sequence number. Using more sequence numbering bits will allow larger flow control
windows to be established in support of high-speed sequential frame transmission.
This option will enable end-to-end or hop-by-hop error and flow control to be
provided when necessary on a labeled packet basis. In applications of mobile ad
hoc networking, it is necessary to have the option of hop-by-hop error and flow
control.
The WMPLS protocol structure is provided below. The payload field (not shown) will
follow the time-to-live (TTL)/CRC field (variable length).
Jong-Moon Chung, et al. March 2002 Page <3>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
WMPLS Header with no control field and no CRC field:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F | Label | CoS |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
WMPLS Header with 3-bit sequence number control field and CRC field:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F | Label | CoS |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N(S)|ARQ| N(R)| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
WMPLS Header with 7-bit sequence number control field and CRC field:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| F | Label | CoS |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| N(S) |ARQ| N(R) | CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TABLE 1. WMPLS header Flag bits.
+--------------+------------------------------------------------------+
| F | Control Field Sequence Numbers N(R) & |
| (Flag) | N(S) and 2-bit FEC & ARQ control field. |
+-------+------+------------------------------------------------------+
| 0 | 0 | No Control and No CRC Field. |
+-------+------+------------------------------------------------------+
| 0 | 1 | 3-bit N(R) and 3-bit N(S). |
+-------+------+------------------------------------------------------+
| 1 | 0 | 7-bit N(R) and 7-bit N(S). |
+-------+------+------------------------------------------------------+
| 1 | 1 | Reserved for future applications. |
+-------+------+------------------------------------------------------+
The Label Distribution Protocol (LDP) and the Resource Reservation Protocol with
Traffic Engineering extensions (RSVP-TE) are the two signaling protocols for MPLS
networking. Both strictly explicitly routing and loosely explicitly routing are
possible for LDP and RSVP-TE. In this document, we focus on the applications of
the loosely explicitly routing topology in WMPLS to enable simple and reliable
soft handover procedures for mobile communications. The section of the wireless
mobile network that may change due to handover procedures will be defined as the
group of abstract nodes. This will enable the wireless network to do handover from
one base station to another within the mobile cellular environment without
breaking the LSP connection. In the following subsections, the proposed extensions
Jong-Moon Chung, et al. March 2002 Page <4>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
to the signaling protocols (i.e., LDP and RSVP-TE) to enable WMPLS networking are
presented.
TABLE 2. WMPLS header flow control and error control acknowledgement control bits.
+--------------+----------------------------------------+-------------+
| ARQ & flow | Flow Control and Error Control | Control |
| control bits | Acknowledgement of frames | Symbol |
+--------------+----------------------------------------+-------------+
| 00 | Accumulative acknowledgement of N(R-1) | RR |
+--------------+----------------------------------------+-------------+
| 01 | Receiver Not Ready flow control and | RNR |
| | accumulative acknowledgement of N(R-1) | |
+--------------+----------------------------------------+-------------+
| 10 | Go-Back_N ARQ REJECT N(R) signal & | REJ |
| | accumulative acknowledgement of N(R-1) | |
+--------------+----------------------------------------+-------------+
| 11 | Selective Reject/Repeat N(R) signal | SREJ |
+--------------+----------------------------------------+-------------+
3. Extensions to the Signaling Protocols for WMPLS Operations
3.1. Extensions to RSVP-TE for WMPLS
RSVP-TE was developed to support LSP control in MPLS networks to support both
strictly and loosely explicitly routed LSPs (ER-LSP) [18]. For the loose segment
in the ER-LSP, the hop-by-hop routing can be used in the Path message forwarding.
For WMPLS LSP setup, a Path message will be transmitted by the source router. In
the Path message, the LABEL_REQUEST object will request the desired label types
for WMPLS setup operations informing the nodes of the desired LSP to reserve the
requested traffic parameters. The extension necessary to trigger a WMPLS LSP
through RSVP-TE will need to have new C-Type assignments within the LABEL_REQUEST
object such that proper wireless traffic parameters and connection types can be
recognized in the Path message.
The format of the Path message and the Resv message in support of wireless
applications follows the format of [3] with extension to the Label Request Object.
3.1.1. Extensions to the Label Request Object
Among the objects of the Path message the Label Request Object requires extensions
to be made to deal with the wireless application labels. The Label Request Class
is 19. Based on RFC 3209 [3], there are three possible C_Types specified under the
Label Request Class=19 [3]. Type 1 is a Label Request without label range. Type 2
is a label request with an ATM label range. Type 3 is a label request with a
Frame Relay label range. In order to request a wireless application specified
label an additional wireless label C_Type (Wireless Label) is defined. The
WIRELESS_LABEL_REQUEST object format is shown below.
Jong-Moon Chung, et al. March 2002 Page <5>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
Wireless Label Request object:
Class = 19, C_Type = WIRELESS_LABEL_REQUEST
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | F | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved
This field is reserved. It MUST be set to zero on transmission
and MUST be ignored on receipt [3].
F
a Flag identifier. Used to identify the label type (Table 1) [3].
L3PID
an identifier of the layer 3 protocol using this path.
Standard Ethertype values are used [3].
3.1.2. Extensions to the Label Object
The Label Object requires extensions to be made to deal with the wireless labels
contained. In the case where labels are carried in the Resv messages, the wireless
application labels must be distinguished from the generic 32-bit labels [3]. The
LABEL object has the format based on the label type specified in the 2-bits of the
Flag (F) field, as specified in Section 3. The Label object class = 16 and the
C_Type = WIRELESS_LABEL. The label for a sender must immediately follow the
FILTER_SPEC for that sender in the Resv message [3].
3.1.3. Hop Count & Sequence Number (HCSN) Object
This optional object is to provide the necessary hop count and message sequence
numbering required in MANET LSP setup applications. The procedural details of the
LSP setup are provided in section 5.3.1.2. The information from this object is
used to distinguish multiple receptions of the same frame in MANET applications.
For this new object a new class and C_Type number needs to be assigned.
Hop Count and Sequence Number object:
Class = HCSN, C_Type = HOP_COUNT_SEQUENCE_NUMBER
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hop Count
records the current hop count of the message. It must be set to zero on
Jong-Moon Chung, et al. March 2002 Page <6>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
transmission and must be increased by 1 on reception at each node.
Message Sequence Number
records the current message sequence number. Each source may begin from a
random number and for the next message transmitted message sequence
number must be increased by 1. After the number reaches its upper limit,
it must return to zero.
3.2. Extensions to LDP for WMPLS
The extensions to LDP [2,14] that need to be made include the Wireless Label
Request and Wireless Label Mapping messages, since the protocol label format needs
to be considered. Wireless application extensions to some of the Type-Length-Value
(TLV) fields are necessary to inform the required label type and flow and error
control operations.
3.2.1. Wireless Label Request Message
A LSR transmits the Wireless Label Request Message to an LDP peer to request a
binding (mapping) for a FEC. The encoding for the Wireless Label Request Message
is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Wireless Label Request | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message [2].
FEC TLV
The FEC for which a label is being requested [2].
Optional Parameters
This variable length field contains 0 or more parameters, each
encoded as a TLV. The optional parameters are defined in [2].
3.2.2. Wireless Label Mapping Message
A LSR transmits a Wireless Label Mapping message to a LDP peer to advertise FEC-
label bindings to the peer in response to the Wireless Request message that was
received. The encoding for the WMPLS Label Mapping Message is:
Jong-Moon Chung, et al. March 2002 Page <7>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Wireless Label Mapping | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Message ID
32-bit value used to identify this message [2].
FEC TLV
Specifies the FEC component of the FEC-Label mapping being Advertised [2].
Label TLV
Specifies the Label component of the FEC-Label mapping [2].
Optional Parameters
This variable length field contains 0 or more parameters, each encoded as a
TLV. The optional parameters are defined in [2].
3.2.3. Extensions to the Label TLV.
Label TLVs encode labels, and are carried by the messages to advertise, request,
release and withdraw label mappings [2]. There are several different kinds of
Label TLVs which can appear in situations that require a Label TLV. In [2] three
types of Label TLVs are defined, namely, Generic Label TLV, ATM Label TLV, and the
Frame Relay Label TLV. For the wireless applications a Wireless Label TLV is
necessary.
The Wireless Label TLV will have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Wireless Label | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Label-1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ . . . . ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Label-N ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label
A WMPLS label (32-bits, 48-bits, or 56-bits) is recorded. The 2-bit flag at
the beginning of the label will indicate the WMPLS label type recorded.
Jong-Moon Chung, et al. March 2002 Page <8>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
4. Handover in WMPLS Mobile Communication Networks
For data communication between two hosts, the forward and the reverse paths can be
either symmetric or asymmetric with respect to data rates and/or bandwidth. For
example, the bandwidth required to download data is commonly higher compared to
the bandwidth required for requests and control messages. The same is not true for
voice communication, where the bandwidth required for both forward and reverse
paths are the same.
First, we summarize some of the terminologies that will be used:
(1) Mobile Host (MH): A host that is nomadic in nature.
(2) Base Station (BS): A service provider that governs all the users connected
to it.
(3) Mobile Switching Office (MSO): The routers that provide access points to MHs
enabling connection to the network.
(4) Mobile Switching Office Gateway (MSO-GW): This is an MSO that lies at the
border of the mobile communication network and the wired backbone network.
4.1. The Proposed Network Topology
As described in the previous sections, WMPLS works with the signaling protocols,
such as, LDP and RSVP-TE. LDP is a hard state protocol, i.e., once a LSP is
established it is assumed that this LSP stays alive until the end of communication
or until it is intentionally disconnected. On the other hand, RSVP-TE is a soft
state protocol, i.e., an established path has to be refreshed periodically for the
LSP to stay alive. Both of these protocols can be either strictly explicitly
routed or loosely explicitly routed [18]. In strictly explicit routing, each node
to be traversed to reach a destination is explicitly specified, whereas in loosely
explicit routing, not all nodes to be traversed to reach the destination are
specified [18]. The nodes that are not specified in the explicit path list in
loose routing are called abstract nodes. In this document, we propose a network
configuration method that applies loosely explicitly routed LSP setup for WMPLS
networks. An example of the topology is illustrated in Fig. 1.
Jong-Moon Chung, et al. March 2002 Page <9>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
. +-------+ +-------+
. |MS0 2.2|---|MSO 2.1|
. +-------+ +-------+
. / \ \
. / \ \
. / \ \
. / \ \ /\
+-----+ +-----+ +------+ \ +-----+ +-----+ / \
|LSR A|---|LSR B|---|MSO-GW| \ |MSO 2|---|MSO 1|----/ BS1\
+-----+ +-----+ +------+ \ +-----+ +-----+ +------+
. \ \ / //
. \ \ / //
. \ \ / +--+
. +-------+ +-------+ |MH|
Backbone . |MSO 2.4|---|MSO 2.3| | |
Network . +-------+ +-------+ +--+
. Mobile Communication Network
Fig. 1. An example of a WMPLS network.
4.1.1. Initial Path Setup
In this section, initial path setup is explained based on Fig. 1, where, the MH
requests a connection to LSR A. Here, the MSO-GW is an MSO that exists at the
border of the mobile communication network and the backbone network. Since the MH
continues to roam and thus requests connection to different BSs, the path between
the MH and the MSO-GW keeps changing. Hence, it would be beneficial for the path
that exists between the MH and the MSO-GW to be defined as the loosely explicitly
routed part of the overall LSP that exists between the MH and LSR A. The steps
involved in establishing the LSP from the MH to LSR A have been discussed in
detail in the following with reference to Fig. 2. In the following example we
assume that the proposed RSVP-TE extensions of Section 3.1 (or LDP extensions of
Section 3.2) are being used as the signaling protocol for WMPLS.
(1) The MH first identifies and connects to its service-providing base station
(BS1).
(2) The MH requests for a connection to LSR A by sending a Path message to BS1.
Since BS1 is directly connected to MSO 1, this Path message will reach the MSO
1.
(3) MSO 1 identifies a path to reach LSR A as MSO 1 -> MSO-GW -> LSR B -> LSR A.
Thus the overall path from the MH is MH -> BS1 -> MSO 1 -> MSO-GW -> LSR B ->
LSR A. Here, the path between the MH and the MSO-GW is the loosely explicitly
routed part and the path between the MSO-GW and LSR A is the fixed part of the
overall LSP from the MH and LSR A.
(4) Then, a path between the MSO 1 and the MSO-GW is chosen (see Fig. 1). In this
example, to reach the MSO-GW from the MSO 1, there are four possible paths,
where, for this example, we will assume that the path selected is MSO 1 -> MSO
2 -> MSO 2.1 -> MSO 2.2 -> MSO-GW. Thus the complete overall path is MH ->
BS1-> MSO 1-> MSO 2 -> MSO 2.1 -> MSO 2.2 -> MSO-GW -> LSR B -> LSR A.
(5) The Path message sent by the MH traverses the selected path through all the
nodes until it reaches LSR A.
(6) The Resv message is then sent by LSR A, which traverses the selected path to
MH. At all nodes, the reservation and allocation of resources takes place.
Jong-Moon Chung, et al. March 2002 Page <10>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
Labels are also assigned to individual links in the LSP. The path established
will support traffic flowing from the MH to LSR A only as RSVP-TE as well as
LDP are unidirectional signaling protocols.
(7) Along with the Resv message, LSR A also sends a Path message in order to
establish a path from LSR A to the MH.
(8) MH sends back a Resv message to LSR A. Then, resource allocation and label
assignments for individual links are performed for the path from LSR A to the
MH.
As mentioned earlier, the resource requirements for these two paths may be
different, thus creating an asymmetric or symmetric connection based on the
request.
LSR A LSR B MSO-GW MSO 2.2 MSO2.1 MSO 2 MSO 1 BS1
| | | | | | |(1) Path|
|<---------|<--------|<--------|<--------|<--------|<------|<-------|
| | | | | | | |
| (2) Resv | | | | | | |
|--------->|-------->|-------->|-------->|-------->|------>|------->|
| | | | | | | |
| (3) Path | | | | | | |
|--------->|-------->|-------->|-------->|-------->|------>|------->|
| | | | | | | |
| | | | | | |(4) Resv|
|<---------|<--------|<--------|<--------|<--------|<------|<-------|
| | | | | | | |
| / | | | | | | \ |
| /=======|=========|=========|=========|=========|=======|=====\ |
| / (5) Bidirectional Data Exchange \ |
| \ / |
| \=======|=========|=========|=========|=========|=======|=====/ |
| \ | | | | | | / |
Fig. 2. Initial Path Setup (the order of the messages are numbered)
In the initial path setup, when applying the proposed LDP extension of Section
3.2, all the steps are similar to the RSVP-TE case described above. The difference
is that the Label Request message will be used instead of the Path message and the
Label Mapping message will be used instead of the Resv message. In addition, LDP
will reserve all required traffic bandwidth and service features as the Label
Request message traverses the downstream path. In the upstream path of the Label
Mapping message, only the labels will be assigned to the individual LSP links.
Compared to this, in RSVP-TE, the bandwidth, service features, and labels will all
be reserved when the Resv message is sent in the upstream path.
Jong-Moon Chung, et al. March 2002 Page <11>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
4.1.2. Path Establishment during Handover
+-----+ +-----+ +------+ +-------+ +-------+ +-----+ +-----+
|LSR A|--|LSR B|--|MSO-GW|--|MSO 2.2|--|MSO 2.1|--|MSO 2|--|MSO 1|
+-----+ +-----+ +------+ +-------+ +-------+ +-----+ /+-----+
. \ /
. \ +---+
. \ |BS1|
Backbone . \ / +---+
Network . \ +--+ /
. \ |MH|
. Mobile \ +--+ \
. Communication \ \ +---+
. Network \ |BS2|
\ +---+
\ \
+--------+ +--------+ +------+ \+------+
|MSO 2.2A|--|MSO 2.1A|--|MSO 2A|--|MSO 1A|
+--------+ +--------+ +------+ +------+
Fig. 3. Path Establishment during Handover
MSO-GW MSO 2.2A MSO 2.1A MSO 2A MSO 1A BS2
| | | | |(1) Path |
|<--------|<--------|<--------|<--------|<--------|
| | | | | |
|(2) Resv | | | | |
|-------->|-------->|-------->|-------->|-------->|
| | | | | |
|(3) Path | | | | |
|-------->|-------->|-------->|-------->|-------->|
| | | | | |
| | | | |(4) Resv |
|<--------|<--------|<--------|<--------|<--------|
| | | | | |
Fig. 4. Message and Data Flow during and after Handover
A soft handover procedure is initiated as soon as a need for handover is detected
by the MH. As soon as a need for handover is detected, the MH identifies the new
BS (BS2) in its reception area. While the currently established connection through
BS1 is still kept alive to receive and transmit packets during handover, the MH
tries to find another path to reach the MSO-GW through BS2 (Fig. 3 & Fig. 4). In
handover procedures, an intermediate router in the loose LSP part that can support
changes of the handover switching paths will be identified and used as the
connecting point of the changing handover paths. In the operations described
below, we make the assumption that the MSOs (which are LSRs) know of the network
connections. When the MH decides that a handover is necessary, it will inform the
new BS (BS2) of this handover by sending a RSVP-TE Path message or a LDP Label
Request message. This information will directly arrive at the adjacent MSOs of BS1
Jong-Moon Chung, et al. March 2002 Page <12>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
and BS2 (i.e., MSO 1 and MSO 1A, respectively). When the MHÆs request for handover
reaches MSO 1A, it will identify BS1 as being connected to MSO 1 and will also
identify the MSO-GW as the router that the loose path adaptation needs to be
requested to. In the following procedures we will assume the RSVP-TE extensions of
Section 3.1 are being applied.
(1) The MH sends a Path message (or Label Request message in LDP) to BS2,
requesting connection to LSR A. Since MSO 1A is directly supporting BS2, it
will receive the Path message (or Label Request message in LDP). Since MSO 1A
identifies that the MSO-GW is the common node where the LSPs meet, it selects
a path to reach the MSO-GW as MSO 1A -> MSO 2A -> MSO 2.1A -> MSO 2.2A -> MSO-
GW. The overall path from the MH through BS2 thus being MH -> BS2 -> MSO 1A ->
MSO 2A -> MSO 2.1A -> MSO 2.2A -> MSO-GW.
(2) A Path message (or Label Request message in LDP) sent by the MH traverses the
selected path through the nodes in the selected path only up to the MSO-GW.
The path from the MSO-GW to the LSR A remains fixed.
(3) The Resv message (or Label Mapping message in LDP) is then sent by the MSO-GW,
which traverses the selected path in the reverse direction to the MH. At all
nodes, the reservation and allocation of resources takes place. (In LDP, the
reservation of the resources would have taken place along with step 2.) Labels
are also assigned to individual links in the new LSP.
(4) Along with the Resv message, the MSO-GW also sends a Path message (or Label
Request message in LDP) in order to establish a path from the MSO-GW to the
MH.
(5) The MH sends back a Resv message (or Label Mapping message in LDP). Then the
resource allocation and the label assignments for individual links are
performed for the LSP from the MH to the MSO-GW. (In LDP, the resource
allocation would have taken place along with step 4.)
(6) Once this path is successfully established, data packets will be forwarded
through the newly established path and the former path from the MH through BS1
to the MSO-GW (MH -> BS1-> MSO 1-> MSO 2 -> MSO 2.1 -> MSO 2.2 -> MSO-GW) will
be disconnected.
4.2. WMPLS Over IMT-2000
In this section we look into the operations of WMPLS applied in an overlay model
having the International Mobile Telecommunications-2000 (IMT-2000) wireless
communication network architecture as the lower layer architecture.
The objectives of IMT-2000 are to provide adaptive communication data
rates(128/144/384 Kbps) under roaming conditions, and a peak data rate of 2.048
Mbps under good stationary conditions. To provide QoS, dedicated bandwidth, and
differentiated services over the network, WMPLS can work in an overlay fashion
with IMT-2000. This section addresses the interoperability issues between WMPLS
and IMT-2000 in order to make the overlay model possible.
In the IMT-2000 network, a specific area is split into cells (Fig. 5). Each cell
is identified with a pseudo random noise (PN) sequence being used by the MHs and
BS in that cell. Each user is identified uniquely, and valid users are identified
using authentication procedures. Since the authentication procedure is conducted
at the lower layer (the IMT-2000 layer), there is no need for a separate
authentication procedure required in the WMPLS layer. After the authentication
procedures of the IMT-2000 system have been successfully completed, the mobile
Jong-Moon Chung, et al. March 2002 Page <13>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
system and the BS will be able to send and receive packets. Through this
established channel, the MH establishes a WMPLS path as explained in section
4.1.1. Any WMPLS packet that is sent is encapsulated within the IMT-2000 protocol
payload.
The user authentication will become necessary when WMPLS is used without any
underlying wireless protocols. User authentication procedures through extensions
of LDP and RSVP-TE for WMPLS networks are left for future development.
. | Backbone .
. | Network .
. +------+ . Mobile
. . . .|MSO-GW|. . . . Communication
/ +------+ \ Network
/ | \
+-----+ | +-----+
|MSO 3| | |MSO 2|
+-----+ | +-----+
+-----+ \
-------|MSO 1| \
/ +-----+ \
/ | \
---------/- | ---\--------
/ / \ | / \ \
/ +------+ \ | / +------+ \
/ |BS 1.2| \ ------|----- / ----| BS 2 | \
\ +------+ / +------+ \/ PN2+------+ /
\ / |BS 1.1| /\ /
\ / +------+ / \ /
------------ \ \ +--+ / ------------
\ PN1 ---|MH| /
\ +--+ /
------------
Fig. 5. WMPLS Over IMT-2000
As an example, shown in Fig. 5, the MH is connected to BS1.1. The PN sequence used
in that cell is assumed to be PN1. Additionally, we also assume that the MH
detects a need for handover and is expecting the communication link to be handed
over to BS2, which belongs to another cell with a different PN sequence, PN2.
Assuming overlapping coverage ranges of the BSs, the following steps [16] are
carried out:
(1) The MH performs the initial cell search and acquires the scrambling code for
BS2, and finds the broadcast control channel (BCCH).
(2) The MH then acquires the primary unmodulated synchronous channel (SCH) and
obtains the timing information for the secondary SCH.
(3) Once acquiring the secondary SCH, the MH achieves the synchronization to BS2.
(4) The MH then calculates the timing difference between the two downlinks of BS1
and BS2.
(5) MH reports this time difference to BS1.
Jong-Moon Chung, et al. March 2002 Page <14>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
(6) BS1 adjusts the timing of the new downlink soft handover connection to one
symbol resolution. BS1 continues to deliver the packets to and from the MH in
this adjusted downlink connection.
(7) Keeping the BS1 downlink connection alive, the MH establishes the LSP to the
MSO-GW through BS2 with the help of MSO 1A. The resource requirements
requested of this new path to the MSO-GW through BS2 will be the same as that
of the current path to the MSO-GW through BS1. Since WMPLS uses RSVP-TE or LDP
as the signaling protocols, such negotiation procedures can be performed
during handover in order to get the same TE parameters.
(8) Once the new path through BS2 to the MSO-GW with same TE parameters is
established, the path through BS1 to MSO-GW is terminated.
Thus, through these procedures soft handover can be achieved in the overlay model
of WMPLS over IMT-2000. Similar procedures can be applied when WMPLS is used in an
overlay architecture with other wireless systems. One advantage of applying WMPLS
procedures over an IMT-200 link is that the IMT-2000 connection in support of the
wireless network is focused on the connection of the BS to the MH, while WMPLS is
capable of providing a single connection or multiple connections over a single
wireless link. This is especially beneficial when a MH needs to establish a point-
to-multipoint connection or when it needs to conduct simultaneous data
communication functions of other devices attached to the MH system, where the MH
is communicating over the network simultaneously with these attached devices.
Other benefits can be seen when multiple devices may be communicating through a MH
using the MH to BS connection as a relay path. Applications of this type are very
common in ad hoc networking which is explained in further detail in Section 5. In
addition, interoperability of the networking protocols with future MPLS, GMPLS, or
MPLambdaS networks is another essential reason that WMPLS technology has been
developed.
5. WMPLS Mobile Ad Hoc Networking Support
This section references [19] for background and conceptual purposes. It also
summarizes some of the definitions of the Cambridge Mobile Ad hoc Routing Protocol
as the groundwork for the research presented in this document. References [12],
[13] and [15] are related to Mobile Ad hoc Networks (MANETs) and a framework for
IP routing in dynamic environments. These concepts are visited in order to present
a comparison framework for the new definitions introduced in this document.
5.1. Ad Hoc and Mobile Ad Hoc Networks
A mobile ad hoc network is characterized by the randomness in its conformance and
by the difficulties that imply performing routing tasks in an uncertain, dynamic
and fast-changing network environment. An ad hoc network can be considered as a
more generalized concept of a mobile ad hoc network in which the mobility of the
communicating nodes may or may not be present. The architecture of an ad hoc
network can be primarily described by the lack of a BS that otherwise would serve
as a point of contact between the wired and the wireless networks, and that would
control and manage its network functions. The major disadvantage is that the
control and management of the links that make up the ad hoc network have to be
decentralized between all the participating nodes. However, the nonexistence of a
base station avoids having to deal with handover issues, bringing down the
complexity of the procedures for dynamically changing networks and roaming MHs.
Jong-Moon Chung, et al. March 2002 Page <15>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
Additional characteristics of ad hoc and mobile ad hoc networks are explained
below.
5.1.1. Connection Types
The nodes inside an ad hoc network can be connected in two ways: peer-to-peer or
remote-to-remote [19]. The peer-to-peer connection type can be seen between
neighboring devices that are not more than one radio hop away. The remote-to-
remote connection type relates to the establishment of a route between two nodes
that implies using intermediate nodes as part of the path. WMPLS maintains
information of the neighboring nodes by means of a peer-to-peer connection, and
utilizes signaling protocols (such as LDP and RSVP-TE) for permanent, temporary,
or momentary connections between source and destination nodes.
5.1.2. Node Mobility Types
Depending on the role of the nodes involved and the nature of the mobility (within
the ad hoc network or between ad hoc networks), the connections will be modified
minimally or substantially. For minimal connection impact, which implies a spatial
change of the source, destination, and/or intermediate node, the mechanisms
provided by LDP and RSVP-TE for route recalculation will be used. Furthermore,
since LDP is a hard-state protocol and RSVP-TE is a soft-state protocol, different
approaches will be used in order to maintain the remote-to-remote connections.
However, for the case in which the mobility implies nodes shifting to and from
other ad hoc networks, a hierarchical addressing methodology that supports dynamic
route recalculation between networks is recommended to be used for scalability.
Regardless of the node addressing topology applied, the traffic engineering
performance and features of WMPLS networking can be supported.
5.1.3. Traffic, QoS and Traffic Engineering Parameters
The traffic patterns in an ad hoc network depend on the type of connection.
Additionally, as explained in [19], a hybrid ad hoc mobile communication pattern
that involves fast-moving nodes that create an unstable mobile network can be
found. As expected, the QoS and traffic engineering parameters included in a MPLS
framework will be highly dynamic and challenging to manage despite the
availability of mechanisms provided by the signaling protocols.
An important issue regarding routing also arises. Since any node can become a
relay agent for any remote-to-remote connection, traffic aggregation has to be
considered. A way to ensure that the communication links will not be disconnected
under circumstances in which the network cannot provide the necessary resources to
guarantee the QoS and TE parameters, adaptation procedures of the bandwidth, QoS,
and GoS must be implemented. In these procedures, reduced QoS and TE values will
have to be flexibly and efficiently negotiated. This will reduce the performance
of the link but will increase the probability of call acceptance.
5.1.4. Neighbor Discovery
For any ad hoc network to function properly, the mechanism for discovering
neighboring nodes to establish a communication link must be present. The use of
beacon signals [19] for neighbor location purposes, and the use of Hello messages
Jong-Moon Chung, et al. March 2002 Page <16>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
for exchanging information are common ways to establish connectivity among peer
nodes within a specific transmission range. Further details on how WMPLS carries
out these procedures are explained in the following.
5.1.5. Size and Bandwidth Utilization
The transmission power for the beacon signal also determines the range and
diameter of the user discovery area. The use of the beacon signal enhances the
reuse of bandwidth among other nodes inside the ad hoc network, and most
importantly, ensures that a large number of nodes can be part of the ad hoc
network at any time.
5.2. WMPLS Performance Considerations
The performance considerations of a mobile ad hoc network cannot commonly be
compared with the performance considerations of a connection-oriented wired
network due to the possible noise and interference factors that the wireless
channel may experience. Thus, the metrics and parameters considered for
performance evaluation are in general considerably different from the already
established parameters for wired networks. In [13] there are several performance
criteria defined, that are both qualitative and quantitative. Out of this list,
several concepts match with the design initiatives of WMPLS. For example, WMPLS
follows a decentralized and distributed operation scheme based on a neighbor-
discovery mechanism.
Additionally, the remote-to-remote links established comprise of unidirectional
links ensuring loop-free operations. This results from the fact that LDP and RSVP-
TE are inherently unidirectional. Hence, a route calculation will involve both the
downstream and upstream calculations for which the results can be different.
Some quantitative metrics utilized to analyze the network performance are: end-to-
end data throughput and delay, route acquisition time and the percentage of out-
of-order delivery of packets [13]. For this document, however, additional metrics
will be involved due to the specific characteristics of a WMPLS mobile ad hoc
network. The metrics considered comprise of reliable adaptability to link
fluctuations, timely reaction to topology changes, link capacity [19], duration of
a remote-to-remote link, and additional load imposed to a node performing relay
functions. Some of these metrics have to deal directly with provisioning of QoS
and TE guarantees for Differentiated Services (DS), and will be carefully reviewed
in the following sections.
5.3. WMPLS Ad Hoc Networking (WMPLS-AHN) Mechanisms
In this section, the specific mechanisms, messages and extensions necessary for
establishing ad hoc networks with WMPLS will be explained. As mentioned before,
depending on the type of mobility incurred by the nodes (either within or between
ad hoc MANETs), two different link connection mechanisms and management procedures
will be used. The following subsection discusses the mobility issues within a
MANET. Section 5.3.2 discusses the mobility issues between MANETs.
Jong-Moon Chung, et al. March 2002 Page <17>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
5.3.1. WMPLS-AHN within a MANET
The procedures required to establish a working MANET using WMPLS involves four
stages:
(1) Neighbor discovery
(2) Initial route calculation
(3) Route re-calculations
(4) Route tear-down
5.3.1.1. Neighbor Discovery
This procedure allows a node to be aware of adjacent nodes, and does not perform
connection setup; it merely collects information of the nodes present and their
characteristics. In order to determine if there are any nodes present, the device
will use a beacon signal that will be power regulated depending on the density of
nodes within the vicinity. If the number of nodes is increased, then the beacon
signal transmission power will be decreased in order to minimize the amount of
interference among other users. The beacon signal does not carry any information
or identification packets and is used only to determine the presence of other
hosts.
Once a node is found to be inside the area of transmission, a Neighbor Discovery
message will be issued. This message will contain the information about the
issuing node and it will be broadcast with enough power to reach only the adjacent
nodes. The Neighbor Discovery messages are not relayed. The receiver of the
message will then collect and process the information contained in the message and
will store in its Adjacencies Table [15].
The RSVP-TE Hello message enables LSRs to detect its current neighbors [3]. The
Hello mechanism enables a LSR to do node failure detection [3]. The RSVP-TE Hello
mechanism composes of a Hello message, a HELLO REQUEST object and a HELLO ACK
object [3]. For LDP [2], the LDP Basic Discovery procedures require periodic LDP
Link Hello messages to be transmitted to its interfaces [2]. The LDP Link Hello
messages are transmitted as UDP packets that are addressed to the well-known LDP
discovery port for the "all routers on this subnet" group multicast address [2].
LDP sessions between indirectly connected LSRs are supported by LDP Extended
Discovery. In addition to the LDP Basic Discovery procedures, in order to engage
in LDP Extended Discovery procedures, a LSR may periodically transmit LDP Targeted
Hellos to specific addresses [2]. LDP Targeted Hellos contains the LDP Identifier
as optional information and are transmitted as UDP packets to the well-known LDP
discovery port at the specific address [2].
Jong-Moon Chung, et al. March 2002 Page <18>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
----------- ------------
/ \ / \
/ +------+ \ --------- / +------+ \
/ | MH | \/ \/ | MH | \
\ +------+ / +------+ \ +------+ /
\ N0 *<--------| MH |--------->* N2 /
\ / +------+ \ /
------------ \ N1 / ------------
\ /
\ /
\ /
----------
* Neighbor Discovery Message
Fig. 6. Neighbor Discovery process
Some additional information that may be contained in the Neighbor Discovery
message includes information of other one-hop-away devices that the issuing node
will have at the moment. This allows for devices to maintain a list of devices
that are at least one hop distance from neighboring nodes. The procedure for
distributing this information resembles the mechanism of the optimized link-state
routing protocol [12]; however, the information may include the number of active
remote-to-remote links as well as peer-to-peer links, the link direction and
characteristics, and a time stamp that will be used to avoid packet duplication.
This information will be used in order to determine the availability of resources
for QoS and TE parameter negotiation. Fig. 6 illustrates the Neighbor Discovery
process using the beacon signal coverage area for establishing the adjacencies.
Note the Neighbor Discovery messages are valid only inside a nodeÆs coverage area.
Upon reception of a Hello message, the receiving node will evaluate the
information and will decide whether to:
* insert the information about a new node entering the MANET
* update the information for a mobile node
* delete the entries associated with a node that has left the MANET
The periodicity of the Hello message will depend on the number of nodes within the
MANET, avoiding flooding of information that can degrade the quality of the
transmissions inside the MANET.
5.3.1.2. Initial Route Calculation
The initial calculation of a route will be triggered by an upper layer
application. The calculation of the route will yield a unidirectional route, as
explained before. The source node will issue a Connection Request message (Label
Request message for LDP or Path message for RSVP-TE) in a broadcast fashion for
the nodes located within one radio hop. This controlled broadcast is possible due
to the information gathered by the Neighbor Discovery process. The messages used
in the initial route calculation should also include a list of all the nodes that
are adjacent to it that should validate the message (Possible Intermediate Node
Jong-Moon Chung, et al. March 2002 Page <19>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
(PIND) list). This PIND list will later be modified and will include only the
nodes that can provide the necessary DS requirements, and the nodes excluded from
the list will silently drop the message [12].
The Connection Request message may contain additional information regarding MANET
specific details, such as a Message Sequence Number [12, 15], a Hop Count
(initially set to 0 since it is being broadcasted by the source node) [12, 15],
the QoS, and TE parameters. This information prevents the nodes from duplicating
the messages and from creating loops. It also ensures DS features for the link.
Setting up a LSP can be done in two ways: (i) End-to-End LSP Setup and (ii) Hop-
by-Hop LSP Setup.
(i) End-to-End LSP Setup:
(1) When the intermediate nodes receive a Connection Request message, they
validate the information received in the message by verifying the values. If
the values are invalid, the packet will be silently dropped. If the packet is
valid, the receiving node will verify the link operational parameters to see
whether the DS request can be supported. If so, the node will update its
Adjacency Table information, and will assign a label for the connection being
established.
(2) The intermediate node then will create a new Connection Request message and it
will send it via broadcast to the adjacent nodes. The message will include
updated information about the Hop Count, Message Sequence Number and QoS and
TE parameters depending on its own status, but it will keep the Request
Identifier for the case in which the source receives the message to silently
drop it. For LDP, the Hop Count TLV appears as an optional TLV in messages
that are used to establish LSPs [2]. The Hop Count TLV records the number of
hops along the LSP as the setup of the LSP is being conducted [2]. The
sequence number can be identified with the application of the Configuration
Sequence Number TLV [2]. For the case with RSVP-TE, the Hop Count & Sequence
Number Object of section 3.1.3 can be used to provide this functionality.
----------- ------------
/ \ / \
/ +------+ (2)\ --------- / +------+ \
/ | MH0 |---------> <----------| MH2 | \
\ +------+ / +------+ (2)\ +------+ /
\ <--------| MH1 |---------> /
\ /(1) +------+ (1)\ /
------------ \ (1)| ^ / ------------
/ \ | | /
/ +------+ <-------+ |(3) /
/ | MH3 |------------+ /
/ +------+ \ -------- /
(1) Connection Request message
(2) Connection Response message with Positive Acknowledgement
(3) Connection Response message with Negative Acknowledgement
Fig. 7. Initial Route Calculation
Jong-Moon Chung, et al. March 2002 Page <20>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
(3) If the DS parameters cannot be met, the node will issue a Connection Response
message (Label Mapping message for LDP and Resv message for RSVP-TE) with a
negative acknowledgment towards the upstream node. This will prevent an
upstream node from including this specific host in its PIND list for a random
amount of time.
(4) The controlled flooding will continue until it reaches the destination node.
When the message reaches the destination, the label mappings will be confirmed
by a Connection Response message sent from the destination node towards the
source node. This message will be sent directly from the destination node to
the source through all the intermediate nodes that the original request
message traversed through. In the case that more than one Connection Request
message is received by the destination, the Hop Count and message sequence
number value will determine the route to take. If similar routes are obtained,
the route will be chosen arbitrarily.
(5) The destination node, immediately after issuing the Connection Response
message, will issue a Connection Request message in order to establish another
unidirectional path from the destination to the source node. The procedure
will be same as the one mentioned before, with the difference that the PIND
list will include only the intermediate nodes that comprise the remote-to-
remote link. If the procedure fails somewhere in the middle, the decision of
choosing an alternative link will be left to the intermediate nodes, and if
the process fails, the destination node will initiate a new connection
procedure back to the source for reverse path establishment.
Fig. 7 shows the initial route calculation using End-to-End LSP setup procedures.
MH0 and MH2 return a positive acknowledgement for the Connection Request messages,
implying that the procedure was valid for the entire route. MH3, however, in this
example, returns a negative acknowledgement because it could not find the
appropriate requested resources passing through the intermediate nodes to
establish a path to MH3.
(ii) Hop-by-Hop LSP Setup:
(1) Step 1 is the same as that for End-to-End LSP setup.
(2) The intermediate node then will send back a Connection Response message with
positive acknowledgement and also simultaneously create a new Connection
Request message with updated Hop Count, Message Sequence Number and QoS and TE
parameters. Then the intermediate node may forward this based on a pre-
calculated forwarding table (forwarding case) or may broadcast it to all
adjacent nodes (flooding case).
(3) Step 3 is same as that for End-to-End LSP setup.
(4) Once this path is established all the way to the destination, the destination
node will broadcast the Connection Request message towards the source in order
to setup the reverse path to the source.
When the adjacent nodes use flooding, the connection can be established very
robustly, although a large amount of resources may be wasted. In comparison to
this, the forwarding topology prevents channel resources from being wasted
although requires a pre-calculated forwarding table to be prepared. The advantage
of using Hop-by-Hop LSP setup procedures is that the LSP setup time is very small
compared to that of End-to-End setup procedures.
Jong-Moon Chung, et al. March 2002 Page <21>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
This is because in Hop-by-Hop LSP setup procedures the Connection Response message
confirms the reservation and the labels are issued link-by-link as the LSP is
being setup. But in End-to-End LSP setup procedures, the Connection Response
message is sent only after the entire LSP is setup.
5.3.1.3. Route recalculations
In the event that one of the nodes start moving away from its neighbors with which
it had a peer-to-peer connection then the moving node will try to establish an
alternative connection between itself and the new neighboring nodes by issuing a
Connection Request message. In most cases this may possibly affect the remote-to-
remote connection as well. The information about separation between nodes is
obtained based on the beacon signal and the Neighbor Discovery messages.
Before establishing the path between the moving node and its peer, the node has to
verify that the destination node has not become one of its neighbors, case in
which, a direct connection should be established with the destination node.
If a new connection path between the moving node and its peer is found, the
traffic is rerouted by means of utilizing LDP and RSVP-TE messages. However, if
the link is lost, an entirely new connection procedure has to be performed. Fig. 8
depicts Route recalculation procedures between nodes MH1, MH0 and MH2 using End-
to-End and Hop-by-Hop LSP setup procedures respectively. Since MH1 moves away from
the coverage area of node MH2, a new intermediate peer-to-peer negotiation has to
be done between nodes MH1 and MH0, and similarly between nodes MH0 and MH2.
(3) +------+ (3) +------+
+-------| MH0 |<----------+ +-->| MH2 |
| +------+ | | +------+
| +------+ |
| +----------------->| MH1 |-----+
| | (2) +------+ Peer to
| | ^ Peer Connection
V | |
+------+ |
| MH3 |-----------X---------+
+------+ (1) Broken Link
(1) Broken Link between MH3 and MH1.
(2) Connection Request message is sent by MH3 through MH0 to MH1.
(3) Connection Response message with Positive Acknowledgment from
MH1 through MH0 to MH3.
Fig. 8. Route recalculation procedure
5.3.1.4. Route Tear-Down
A route tear-down is performed when the connection is voluntarily terminated by
any of the remote nodes, or when a new route is calculated due to the mobility of
any of the participating nodes in the path. This message can also be issued due to
an error or inability to provide the DS parameters required for a specific
connection.
Jong-Moon Chung, et al. March 2002 Page <22>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
The Connection Terminate message is used to tear-down the connection between two
peer-to-peer nodes, and contains additional information regarding the magnitude of
the connection termination. The magnitude can be global or partial. When a
voluntary termination or a QoS or TE parameter negotiation failure occurs, a
global termination message can be issued, however, when it comes to route
recalculation, only a partial route termination message is used.
The Connection Terminate message can be implemented applying several messages in
LDP or RSVP-TE based on the connection status. In RSVP-TE, the Connection
Terminate operation can be conducted by the ResvTear message (Msg Type = 6 [3])
that is sent to the upstream LSR [3]. Alternatively a node may terminate its LSP
connections using the PathTear message (Msg Type = 5 [3]), which is sent to its
downstream LSRs [3]. The PathTear message that is inherent in RSVP removes all the
entries in the LSP as well as all reservations. In LDP, the Label Abort Request
message may be used if the LSR is trying to abort an outstanding Label Request
message [2]. A Label Withdraw message may be used to inform a LDP peer that the
specific FEC-label mappings should not be used any further, which results in
breaking the mappings between the FECs and the labels [2]. A Label Release message
is used when the LSR which sent the label mapping is no longer the next hop for
the mapped FEC any more, or the LSR receives a label mapping from an LSR which is
not the next hop for the FEC any more, or as a response message to a Label
Withdraw message [2].
5.3.2. WMPLS between MANETs
Considering the dynamic characteristics of MANETs, cases in which two different
MANETs come in close contact with each other and therefore have to merge into one
network is possible. However, the assumption of independence between MANETs and
any possible interaction between them is defined by the existence of a managing
and controlling base station. If there are no base stations defined, the
interaction of two MANETs can be seen as aggregation of nodes inside a
transmission area in which the procedures mentioned in section 5.3.1 are
applicable.
The presence of controlling and managing BSs arise issues relating to handover
procedures and hierarchical structures. Based on this reason, WMPLS nodes can
achieve remote-to-remote connections among two different MANETs controlled and
managed by the base stations. Fig. 9 shows a hierarchical structure composed of
two ad hoc networks managed and controlled by base stations. Synchronization and
handover procedures are provided by the base stations.
Jong-Moon Chung, et al. March 2002 Page <23>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
+------+ +------+
| MH |<------>| MH |
+------+ (1) +------+
| (1)
V
/\
/ \
/ BS1\
+------+
^
|
(2)| /\
| / \
+---->/ BS2\
+------+
|
| (1)
| +------+ (1) +------+
+---->| MH |<------>| MH |
+------+ +------+
(1) Peer-to-peer Connection
(2) BS-to-BS Connection
Fig. 9. A hierarchical structure
The connection procedures explained in sections 4.1.1 and 4.1.2 will be extended
in order to support the existence of base stations. Additional mechanisms will
also be included that will provide synchronization mechanisms, and are left for
future work and research.
6. Conclusion
WMPLS technology has been developed to provide solutions to most of the
limitations that WATM-ATM networks have and also enable special features like
connectionless ad hoc and mobile ad hoc networks to be established. The procedures
to achieve soft handover in WMPLS has been presented. An overlay model of WMPLS
operating over IMT-2000 has been illustrated. Moreover, WMPLS providing support
for MANETs in support of QoS and/or TE service features have also been discussed.
WMPLS has been developed as a fully compatible protocol with MPLS for enhanced
high-speed translation from the wired network to the wireless portable
transceivers. WMPLS is a homogeneous protocol with MPLS, GMPLS, and MPLambdaS by
protocol architectural design. It also uses the same control signaling protocols
with some extensions, which enables full interoperating features. The basic
protocol format of WMPLS closely resembles the original MPLS protocol, but
includes some wireless application specific extensions. Based on the protocol
format of MPLS and WMPLS, the MSO-GW that works between the backbone network and
the MSO network will only be required to convert MPLS to WMPLS, which will be a
trivial protocol translation task, thus keeping the overall network operations
simple at all LSRs and gateways. If desired, the wireless portable devices can be
Jong-Moon Chung, et al. March 2002 Page <24>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
the originating or receiving router of the connection oriented communication path
enabling streamlined data transferring with minimum translation at the MSO or base
stations. Including the mobile wireless port as a part of the overall network
connection allows the wireless portable device to be a part of the MPLS path. This
enables equivalent features of the MPLS network to exist over the wireless link as
well. In addition, general problems such as interoperability with future MPLS
networks, and supporting and negotiating differentiated services and traffic
engineering features are solved due to the inherent multiprotocol architecture and
additional features that the MPLS networking and signaling protocols provide.
7. References
[1] A. S. Acampora and M. Naghshineh, ææAn architecture and Methodology for Mobile-
Executed Handoff in Cellular ATM Networks,ÆÆ IEEE JSAC, vol.12, no.8, Oct. 1994.
[2] L. Andersson, P. Doolan, N. Feldman, A. Fredette, and B. Thomas, ææLDP
Specification,ÆÆ RFC 3036, The Internet Society, Jan. 2001.
[3] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, and G. Swallow, ææRSVP-TE:
Extensions to RSVP for LSP Tunnels,ÆÆ RFC 3209, The Internet Society, Dec. 2001.
[4] E. Ayanoglu, K. Y. Eng, and M. J. Karol, ææWireless ATM: Limits, Challenges,
and Proposals,ÆÆ IEEE Personal Communications, vol. 12, Aug. 1996.
[5] B. Bing, High-Speed Wireless ATM and LANs. Norwood, MA: Artech House, 2000.
[6] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, "Resource ReSerVation
Protocol (RSVP) -- Version 1, Functional Specification," RFC 2205, The Internet
Society, Sept. 1997.
[7] J.-M. Chung, (Invited Paper) ææWireless Multiprotocol Label Switching,ÆÆ in
Proc. of the 35th Asilomar Conference on Circuits, Systems, and Computers 2001,
Pacific Grove, CA, U.S.A., Nov. 4-7, 2001.
[8] J.-M. Chung, (Invited Paper) ææAnalysis of MPLS Traffic Engineering,ÆÆ
Proceedings of the IEEE Midwest Symposium on Circuits and Systems 2000
Conference (IEEE MWSCASÆ00), East Lansing, MI, U.S.A., Aug. 8-11, 2000.
[9] J.-M. Chung, E. Marroun, H. Sandhu, and S.-C. Kim, ææVoIP over MPLS Networking
Requirements,ÆÆ in Proc. of the IEEE International Conference on Networking 2001
(IEEE ICNÆ01), Colmar, France, July 9-13, 2001.
[10] J.-M. Chung, M. A. Subieta Benito, H. Chhabra, G. Y. Cho, and P. Rasiah,
ææExtensions to LDP for MPLS Multicasting,ÆÆ work in progress, Internet Draft,
The Internet Society.
[11] J.-M. Chung, M. A. Subieta Benito, H. Chhabra, G. Y. Cho, and P. Rasiah,
ææExtensions to RSVP-TE for MPLS Multicasting,ÆÆ work in progress, Internet
Draft, The Internet Society.
[12] T. Clausen, P. Jacket, A. Laouiti, P. Minet, P. Muhlethaler, A. Wayyum,
L. Viennot, ææOptimized Link state Routing Protocol,ÆÆ work in progress,
Internet Draft, The Internet Society.
[13] S. Corson, J. Macker, ææMobile Ad hoc Networking (MANET): Routing Protocol
Performance Issues and Evaluation Considerations,ÆÆ RFC 2501, The Internet
Society, Jan. 1999.
[14] B. Jamoussi, et al., ææConstraint-Based LSP Setup using LDP,ÆÆ work in
progress, Internet Draft, The Internet Society.
[15] C. E. Perkins, E. M. Belding-Royer, S. R. Das, ææAd hoc On-Demand Distance
Vector (AODV) Routing,ÆÆ work in progress, Internet Draft, The Internet Society.
[16] R. Prasad and T. Ojanpera, ææAn Overview of CDMA Evolution toward Wideband
CDMA,ÆÆ IEEE Commun. Surveys and Tutorials, vol. 1, no. 1, Fourth Quarter, 1998.
Jong-Moon Chung, et al. March 2002 Page <25>
Internet Draft draft-chung-mpls-wmpls-00.txt September, 2002
[17] D. Raychaudhari and N. D. Wilson, ææATM based transport architecture for
multiservice wireless personal communication networks,ÆÆ IEEE JSAC, vol. 12, pp.
1401-1414, Oct. 1992.
[18] E. Rosen and A. Viswanathan, ææMultiprotocol Label Switching Architecture,ÆÆ
RFC 3031, The Internet Society, Jan. 2001.
[19] C.-K. Tok, ææWireless ATM and Ad-Hoc Networks: Protocols and Architectures,ÆÆ
Kluwer Academic Publishers, 1997.
8. AuthorsÆ Addresses
Jong-Moon Chung
ACSEL & OCLNB Laboratories
School of Electrical & Computer Engineering
Oklahoma State University
Stillwater, OK 74078
Phone: (405)744-9924
Email: jchung_osu@lycos.com
Kannan Srinivasan
ACSEL & OCLNB Laboratories
School of Electrical & Computer Engineering
Oklahoma State University
Stillwater, OK 74078
Phone: (405)744-2662
Email: kannans@okstate.edu
Mauricio A. Subieta Benito
ACSEL & OCLNB Laboratories
School of Electrical & Computer Engineering
Oklahoma State University
Stillwater, OK 74078
Phone: (405)744-5215
Email: maurici@okstate.edu
Jong-Moon Chung, et al. March 2002 Page <26>