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>