Mobile IP Working Group N. A. Fikouras INTERNET DRAFT C. G÷rg Expires: January 2002 ComNets-ikom, Uni. Bremen W.Zirwas M. Lott Siemens AG July 2001 Filters for Mobile IP Bindings (NOMAD) draft-nomad-mobileip-filters-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 In Mobile IP, a mobile node that maintains simultaneous bindings will receive at each registered care-of address a duplicate copy of every datagram from every active flow. However, a mobile node with multiple points of attachment may wish to receive different flows at each one. The purpose of this document is to enable mobile nodes to associate a list of filters with a binding during its establishment (registration, binding update). In this manner, a mobile node may select for each flow the most appropriate point of attachment. In order not to violate layer independence, the filtering of individual flows or groups of them is managed through flow description components made available by existing approaches to QoS support. NOMAD Expires January 2002 1 Internet Draft Filters for Mobile IP Bindings July 2001 Table of Contents 1 Introduction.....................................................3 2 Terminology......................................................4 3 NOMAD Extensions Protocol Overview...............................5 3.1 Protocol Description............................................5 4 Associating Filters with Bindings................................8 4.1 Mobile Node Considerations......................................8 4.2 Binding Agent Considerations....................................8 5 NOMAD Extensions to RFC2002 Registration Messages................9 5.1 Behavior Aggregate Filters (BAF) Extension.....................10 5.2 Multi-Field Filters (MFF) Extension............................10 5.3 Extended Multi-Field Filters (EMFF) Extension..................11 5.4 Free-Form Filters (3F) Extension...............................12 5.5 Routing Optimization Extension for Simultaneous Bindings......12 6 Intellectual Property Considerations............................13 References........................................................14 Authors' Addresses................................................15 NOMAD Expires December 2000 2 Internet Draft Filters for Mobile IP Bindings July 2001 1 Introduction This document extends the Mobile IP [1] protocol by providing the means for mobile nodes with simultaneous bindings to notify Binding Agents (Mobile IP entities that can maintain simultaneous bindings) of an association between filters and specific bindings. As such, traffic intercepted by, or originating from a Binding Agent will be filtered and individual flows will be redirected to the care-of address indicated by the respective binding. This enables mobile nodes to distribute active flows amongst their available points of attachment. Mobility Agents are unable to distinguish between individual flows and therefore redirect all intercepted traffic for a mobile node to the care-of address indicated by its binding. Consequently, as the binding is updated with every hand-off, the total of a mobile node's active flows are redirected to the most recently registered care-of address. Furthermore, if a mobile node requests for simultaneous bindings, it will receive at each registered care-of address a duplicate copy of every active flow. However, a mobile node that maintains multiple access interfaces and hence multiple points of attachment may wish to associate certain flows with specific access interfaces. As these access interfaces vary their care-of address a mobile node should be able to perform a Mobile IP (IP-layer) hand-off for only a subset of its active flows. A functionality similar to the one described earlier can be provided through the routing optimization extension [3] whereby the mobile node is enabled to communicate directly with a correspondent node (CN), bypassing all mobiliy agents. In that case, it is possible for the mobile node to register a different care-of address with each CN, therefore associating all of a CN's communications with one of its points of attachment. However, with this approach it is not possible to distribute the communications of a given CN between multiple points of attachment. The reason for this is because, in routing optimization, CNs may not maintain multiple bindings for a mobile node. Moreover, CNs, just like mobility agents, are equally unable to distinguish between individual flows in spite of being their origin. Filters for bindings require that a mobile node includes in its registration requests or binding updates a list of filters. Flows that match the conditions listed in the filters are associated with the registered care-of address. In this manner the Binding Agent (CN, Home or Hierarchical Agents) becomes aware of the relationship between certain flows and specific bindings. However, the existence of those filters does not affect in any way the mobile node's choice on the point of attachment to be utilized for the return path. In order to provide simultaneous bindings to CNs with routing optimization support, the 'S' bit is introduced in the binding update message. In order not to violate layer independence, the filtering of flows occurs through components made available by protocols for QoS NOMAD Expires December 2000 3 Internet Draft Filters for Mobile IP Bindings July 2001 support. The consideration presented in this document are collectively referred to as the NOMAD Extension. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [1]. This document uses the following terms: Domain A collection of networks sharing a common network administration. Home domain As defined in [4]. Visited domain The domain where the mobile node has one or more points of attachment. Gateway Foreign Agent (GFA) As defined in [4]. Regional Foreign Agent (RFA) As defined in [4]. Home Agent (HA) As defined in [1]. Home Network As defined in [1]. Correspondent Node (CN) As defined in [1]. Mobile Node (MN) As defined in [1]. Mobility Binding As defined in [1]. Binding Agent (BA) Any Mobile IP entity (HA, GFA, RFA, CN) that can maintain Simultaneous mobility bindings. Binding Request Mobile IP signaling (registration request, binding update) with the purpose of establishing or updating a mobility binding. NOMAD Expires December 2000 4 Internet Draft Filters for Mobile IP Bindings July 2001 Binding Reply Mobile IP signaling (registration reply, binding acknowledgment) for acknowledging the successful updating or establishment of a mobility binding. 3 NOMAD Extensions Protocol Overview This section provides an overview of how filters for Mobile IP bindings can be realized. 3.1 Protocol Description Every time that a mobile node acquires a care-of address through one of its points of attachment it is required to issue a registration request or binding update (collectively termed as binding requests) to the respective Binding Agent. A Binding Agent can be any Mobile IP entity that can maintain bindings, like a HA, GFA, RFA even a CN when routing optimization is supported. In any case, the mobile node is required to include in its binding request a list of filters that indicate which flows are associated with the registered care-of address. The rules by which a mobile node decides on the set of filters is considered beyond the scope of this document. A Binding Agent that receives a binding request that includes a list of filters is required to establish a tunnel as per [1]. However, this tunnel is only applicable for flows that match the criteria present in any of the filters associated with the binding. If a Binding Agent receives simultaneous registrations (bindings) it is required to establish different tunnels, each associated with different filters. It is noted that, filters of simultaneous bindings need not be mutually exclusive. In the case of overlapping filters, the Binding Agent is required to duplicate flows that match the overlapping criteria and direct them to the corresponding care-of addresses. A mobile node may issue filters that correspond to flows that do not yet exist. In that case, when such a flow is initiated it will be handled by the Binding Agents as indicated by the filter. A binding without any filters is considered as the default binding. The default binding is used for all flows for which no filters have been defined. In the absence of filter-less bindings, the default binding is considered the one with the longest outstanding lifetime. It is possible for a mobile node to maintain multiple filter-less as well as other bindings at the same time. In that case, all flows for which a matching filter exists will be directed to the corresponding care-of address while the rest will be duplicated and directed to the care-of addresses indicated by all the filter-less bindings. If a specific filter is not accepted by a Binding Agent then it is required to include this filter in its registration reply/binding acknowledgement (termed collectively as binding reply). Otherwise no NOMAD Expires December 2000 5 Internet Draft Filters for Mobile IP Bindings July 2001 other indication is required. When returning traffic the mobile node is not bound in any way by the extensions presented as to which point of attachment should be used. A filter remains valid for the lifetime of the corresponding binding. When the lifetime of a binding expires then all associated filters are cancelled. In order for a mobile node to modify a filter (add/remove predicates) it is required to issue a new Binding Request for the care-of address associated with the filter, including a new filter entry or the part of the filter that needs to changed. The filter extensions presented later in this document include special fields for filter management. In order to protect layer independence the structure of filters that may be added to a Binding Request is based on existing filter specification for QoS support. 3.2 Model of Operation The general model of operation is illustrated in figure 1. It shows a mobile node that maintains multiple access interfaces. Each interface provides a point of attachment through a visited domain. The extensions presented do not provide any restriction as to how many points of attachment a mobile node may maintain within a domain. For example, the mobile node in figure 1 has two separate points of attachment in the Mobile IP hierarchy of visited domain A. In addition, the mobile node maintains two more points of attachment through visited domains B and C. The extensions presented operate independently of whether the point of attachment provides a normal or collocated care-of address. In figure 1, the mobile node maintains four communications with correspondent nodes CN1 and CN2. Flows associated with CN1 are denoted with 'a' and 'b' while the respective flows for CN2 are denoted with 'c' and 'd'. When routing optimization is used in conjunction with hierarchical Mobile IP the Binding Agent can be the HA or any of hierarchy Mobility Agents such as the GFA and RFA as well as the CN itself. The level at which filtering may occur is determined by the mobile node depending on the micro/macro mobility character of every hand-off as well as internal rules. In general, the Binding Agent that issues the registration reply or binding acknowledgement (collectively termed as binding reply) is also required to deploy the filters. For communications with CN1, routing optimization has been assumed but the GFA has been selected as the filtering Binding Agent. Communications with CN2 do not assume routing optimization and therefore all flows are first directed to the mobile node's HA. In the example presented in figure 1, the mobile node has issued a separate binding request for each care-of address acquired by its NOMAD Expires December 2000 6 Internet Draft Filters for Mobile IP Bindings July 2001 points of attachment. Every binding request contained a set of filters that forces the respective Binding Agents to redirect different flows to different care-of addresses. As such, even though the GFA intercepts the total of CN1's traffic destined for the mobile node, separate flows are directed to different points of attachment. The same is observed at the HA, which intercepts incoming traffic from the CN2 and after filtering it redirects them to different locations. To return traffic a mobile node may choose any of the available points of attachment. +---------------------+ +-------+ | Visited Domain A | | CN1 | | | +-------+ | | |a a a a a a a +------+ a a a | |b -----------| FA |----- | +------|a-----+ a| | +------+ |a | |b | | | +-------+ | |a | a| | | GFA |------------ b | | | +-------+ babababababa | a| | +------+ |b | | | | --------| FA |----- | | | a| |b b b b +------+b b b b | | | | | | | | | a| |b +---------------------+ | Public | +-----------+ +------+ | Network | | | | MN | +---------------------+ | | | Home | +------+ | Visited Domain B | | | | Network | |d |c | | | | | | | | c c c +------+ c c c c c c c c c c c c c c c c c c c c c | |d --------| FA |----------------------------------------- | | | +------+ | | d d d d d d d d d d |c | |d | | | d ------------------ | | | | | | | | | |d |c | |d | | | d| dcdcdcdcdcdc +------+ | | +---------------------+ | | c ------------| HA | | |d | d| d| | | +------+ | | +---------------------+ +-- |--c|-----+ | | |d | | d| d| | | | d d d d d d d d d d d d d d d d d d | c| +-----------+ -------------------------------------- d| | | c| | Visited Domain C | +-------+ | | | CN2 | +---------------------+ +-------+ Figure 1: A mobile node with multiple points of attachment in different visited domains. Incoming flows are redirected by the respective Binding Agents to a different care-of address. NOMAD Expires December 2000 7 Internet Draft Filters for Mobile IP Bindings July 2001 4 Associating Filters with Bindings This section gives a detailed description of the steps taken by a mobile node that wishes to associate filters with its bindings. Furthermore, it is presented how a Binding Agent reacts to the receipt of a binding request containing a list of filters. 4.1 Mobile Node Considerations A mobile node that acquires a care-of address within a domain (home or visited) may issue a binding request containing a list of filters. All included filters will be associated with the registered care-of address at the Binding Agent that issues the Binding Reply. A mobile node that can maintain multiple points of attachment may request for simultaneous bindings by setting the 'S' bit on in its Bindings Requests. However, each of the Binding Requests must contain its own list of filters. Consequently, flows that match any of the filters will be received at the corresponding point of attachment. Similarly, flows that match overlapping filters will be received at multiple points of attachment. Finally, flows that do not match any of the declared filters will be received at the point of attachment indicated by the default binding. Should a Binding Agent fail to apply one of the filters or individual predicates of a filter then it is required to include them in the Binding Reply. If routing optimization is supported then in the case of a declined filter a Binding Acknowledgment with the failed filter must be generated independently of whether the 'A' bit was set in the Binding Update or not. 4.2 Binding Agent Considerations Binding Agents that receive a Binding Request containing a list of filters are required to make a record of the filters regardless of whether they must issue a Binding Reply or not. If the Binding Agent is required to issue a Binding Reply then it is also required to apply the filters, else no further action is required. Should the Binding Agent fail to apply any of the filters then the failed filter (or predicate) must be included with the Binding Reply. If authentication of the Binding Request fails then none of the filters must be applied nor is it necessary to copy them in the Binding Reply. When a Binding Agent intercepts a packet for a mobile node for which it maintains simultaneous bindings it is required to identify whether the packet matches any of the filters. If so, the packet is redirected to the care-of address indicated by the respective binding. If no matching filter is found then the packet is redirected to the care-of address indicated by the default binding. NOMAD Expires December 2000 8 Internet Draft Filters for Mobile IP Bindings July 2001 5 NOMAD Extensions to RFC2002 Registration Messages In this section the new Mobile IP registration extensions required for the support of filters for bindings are specified. Furthermore, the lack of support for simultaneous bindings in CNs with routing optimization requires the introduction of the 'S' bit to binding update message In Differentiated Services (DS) [6] the DS header field is defined as a replacement for the IPv4 TOS [5] and IPv6 Traffic Class [IPv6] octets. Six bits of the DS field are used as a codepoint (DSCP) to select the per-hop-behavior that a packet receives at each node. For the purposes of NOMAD the DSCP along with other header fields is used to construct filters that identify a specific flow or groups of them. In addition, the remaining two bits required by DSCP to complete an octet have been used for the transport of filter management information. In NOMAD, four different types of filters are defined: 1. Behavior Aggregate Filters (BAF). Are based solely on the DSCP field and provide the most fundamental form of filtering. 2. Multi-Field Filters (MFF) Take into account additional fields in the IP header and aim to identify a single flow from a particular sender application. 3. Extended Multi-Field Filters (EMFF) Based on the DSCP with additional fields from the packet header. Enables the mobile node to define ranges of sources as well as port numbers 4. Free-Form Filters (3F) It allows for the definition of complex filters based on the value of an area anywhere within a packet. The mobile node is required to provide the packet offset, the qualifying value as well as a mask. The individual fields of the filters presented are based on the classifier models of the Diffserv management model. The filters presented do not in any way alter or affect the DSCP value of intercepted packets. They only enable a Binding Agent to determine for each packet the most appropriate binding when a mobile node maintains a range of them. Should a Binding Agent fail to apply any of the filters NOMAD Expires December 2000 9 Internet Draft Filters for Mobile IP Bindings July 2001 5.1 Behavior Aggregate Filters (BAF) Extension 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | DSCP |P|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To Be Defined (BA) Length (N), where N is the number of DS field entries DSCP Differentiated Services Codepoint Filter Management An integer specifying how the submitted or existing filters should be managed. The 'A' bit indicates the action to be undertaken (add/remove) while the 'P' bit indicates the purpose of the filter (location privacy/flow distribution). The mechanism by which filters can be used to provide location privacy services will be described in detail in further updates of this document. Admissible values for the 'A' (Action) bit are as follows: Value Filter Management ----- ----------------- 0 remove from filter 1 concatenate to filter Admissible values for the 'P' (Purpose) bit are as follows: Value Filter Management ----- ----------------- 0 Purpose of filter is location privacy 1 Purpose of filter is flow distribution 5.2 Multi-Field Filters (MFF) Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | DSCP |P|A| Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To Be Defined (MF) NOMAD Expires December 2000 10 Internet Draft Filters for Mobile IP Bindings July 2001 Length (8*N), where N is the number of filters associated with the registered point of attachment Protocol Identifies the next level protocol used in the data portion of the internet datagram. The values for various protocols are specified in [3]. 5.3 Extended Multi-Field Filters (EMFF) Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | DSCP |P|A| Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port Number Min | Source Port Number Max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Port Number Min | Destination Port Number Max | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type To Be Defined (Mini IPv4-6-tuple) Length (18*N), where N is the number of filters associated with the registered point of attachment Source Port Number Min Defines the start point of a range of source port numbers Source Port Number Max Defines the end point of a range of source port numbers Destination Port Number Min Defines the start point of a range of destination port numbers Destination Port Number Max Defines the end point of a range of destination port numbers NOMAD Expires December 2000 11 Internet Draft Filters for Mobile IP Bindings July 2001 5.4 Free-Form Filters (3F) Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |P|A| Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value | .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask | .... Type To Be Defined (IPv4-6-tuple) Length Is variable, depends on the length of Value and Mask. Offset Indicates a location within a packet to be filtered in bytes. The area indicated by the offset and for a length equivalent to that of Mask is compared against Mask with the bitwise operator AND. The result of this operation are compared against Value. A match would indicate that the packet qualifies the filter. Value and Mask fields MUST have exactly the same size. However, this size may vary with every free-form filter. For the sizes of Value and Mask the following condition holds: Value = Mask = (Length - 2) / 2 5.5 Routing Optimization Extension for Simultaneous Bindings The Binding Update message is defined in [3]. With this message it is possible for the mobile node to establish a binding with a CN with routing optimization support. However, with every subsequent Binding Update the CN is required to update the binding. In order to enable simultaneous binding support the 'S' bit is introduced in the Binding Update message. It occupies one of previously reserved bits. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |A|I|M|G|S| Rsv | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... NOMAD Expires December 2000 12 Internet Draft Filters for Mobile IP Bindings July 2001 +-+-+-+-+-+-+-+- S Simultaneous bindings. If the 'S' bit is set on, the mobile node is requesting that the correspondent node retain its prior mobility bindings All other fields are defined in [2]. 6 Intellectual Property Considerations This proposal is in full conformity with [10]. Siemens may have patent rights on technology described in this document which employees of Siemens contribute for use in IETF standard discussions. In relation to any IETF standard incorporating any such technology, Siemens hereby agrees to license on fair, reasonable and non-discriminatory terms, based on reciprocity, any patent claims it owns covering such technology, to the extent such technology is essential to comply with such standard. NOMAD Expires December 2000 13 Internet Draft Filters for Mobile IP Bindings July 2001 References [1] C. Perkins. IP Mobility Support. RFC (Proposed Standard) 2002, IETF, October 1996. [2] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, IETF, March 1997. [3] C. Perkins and D. Johnson. Route Optimization in Mobile IP. (work in progress). draft-ietf-mobileip-optim-10.txt, IETF, November 2000 [4] J. Reynolds and J. Postel. Assigned Numbers. Request for Comments 1700, STD 2, IETF, October 1994 [5] E. Gustafsson, A. Jonsson and C. Perkins. Mobile IP Regional Registration. (work in progress). draft-ietf-mobileip-reg-tunnel- 04.txt, IETF, March 2001 [6] Postel, J. Internet Protocol. STD 5, RFC 791, IETF, September 1981. [7] K. Nichols, S. Blake, F. Baker, and D. Black. Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers. RFC 2474, IETF, December 1998. [8] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Specification. RFC 2460, IETF, December 1998. [9] Y. Bernet, S. Blake, D. Grossman and A. Smith. An Informal Management Model for Diffserv Routers. (work in progress). draft- ietf-diffserv-model-06.txt, IETF, February 2001 [10] S. Brander. The Internet Standards Process -- Revision 3. RFC 2026, IETF, October 1996 NOMAD Expires December 2000 14 Authors' Addresses Niko A. Fikouras Department of Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen Phone: 49-421-218-3339 28219, Bremen, Germany Email: niko@comnets.uni-bremen.de Carmelita G÷rg Department of Communication Networks (ComNets) Center for Information and Communication Technology (ikom) University of Bremen Phone: 49-421-218-3339 28219, Bremen, Germany Email: niko@comnets.uni-bremen.de Wolfgang Zirwas Siemens AG ICM N MR-ST 8 Werner-von-Siemens Ring 20 D-85630 Grasbrunn Phone: 49-89-722-34369 Germany Email: wolfgang.zirwas@icn.siemens.de Matthias Lott Siemens AG ICM N MR-ST 8 Werner-von-Siemens Ring 20 D-85630 Grasbrunn Phone: 49-89-722-28097 Germany Email: matthias.lott@icn.siemens.de NOMAD Expires January 2002 15