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>