RFC 5184
Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover
📄 RFC 5184 🎀
- Stream: Network Working Group
- Title: Unified Layer 2 (L2) Abstractions for Layer 3 (L3)-Driven Fast Handover
- Authors: F. Teraoka, K. Gogo, K. Mitsuya, R. Shibui, K. Mitani (all KEIO University) 🎓
- Category: Experimental 🧪
- Date: May 2008 📅
- Obsoletes / Updates: nothing is listed in the title block, so this one doesn't obsolete or update anything 🙅♀️
Status of This Memo 💅
okay so this memo defines an Experimental Protocol for the Internet community 🧪. it does NOT specify an Internet standard of any kind, so don't treat it like one 🙈. the authors are literally asking for discussion and suggestions for improvement 🫶. and distribution of this memo is unlimited, so share it wherever 🌈
IESG Note ✨
this document is not an IETF Internet Standard. it represents the consensus of the MOBOPTS Research Group of the Internet Research Task Force 🔥. it might be considered for standardization by the IETF in the future, so keep an eye out 👀
Abstract 🦋
okay this one is the big-picture pitch 💖. this doc proposes unified Layer 2 (L2) abstractions for Layer 3 (L3)-driven fast handovers. for efficient network communication it's vital that one protocol layer knows about, or can use, another layer's info, like the form of L2 triggers 🧠. the problem? every protocol layer is basically designed independently, and in current operating systems each one is implemented independently too. so exchanging control info between layers is very hard 😭
the fix is nine kinds of L2 abstractions, written as "primitives" 🎀, that help achieve fast handovers at the network layer. it's called "L3-driven fast handovers" because the network layer is the one that kicks off L2 and L3 handovers using those primitives 👑. this document is a product of the IP Mobility Optimizations (MobOpts) Research Group 🌸
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Primitives for L2 Abstractions ..................................4
4. Definitions of Primitives .......................................6
4.1. L2-LinkStatus (Type 1) .....................................6
4.2. L2-PoAList (Type 1) ........................................6
4.3. L2-PoAFound (Type 2) .......................................6
4.4. L2-PoALost (Type 2) ........................................6
4.5. L2-LinkUp (Type 2) .........................................7
4.6. L2-LinkDown (Type 2) .......................................7
4.7. L2-LinkStatusChanged (Type 2) ..............................7
4.8. L2-LinkConnect (Type 3) ....................................7
4.9. L2-LinkDisconnect (Type 3) .................................8
5. Definitions of Static Parameters ................................8
5.1. Network Interface ID .......................................8
6. Definitions of Dynamic Parameters ...............................8
6.1. PoA (Point of Attachment) ..................................8
6.2. Condition ..................................................8
6.3. PoA List ...................................................9
6.4. Enable/Disable .............................................9
6.5. Ack/Error ..................................................9
7. Architectural Considerations ....................................9
8. Security Considerations ........................................13
9. Acknowledgements ...............................................14
10. References ....................................................14
10.1. Normative References .....................................14
10.2. Informative References ...................................14
Appendix A. Example Scenario ....................................16
Appendix B. Example Operation for FMIPv6 ........................17
B.1. Example Operation-1 for FMIPv6 ............................18
B.2. Example Operation-2 for FMIPv6 ............................20
B.3. Experiment ................................................21
Appendix C. Example Mapping between L2 Primitives and
Primitives in IEEE 802.11 and IEEE 802.16e ..........22
Appendix D. Example Mapping of Primitives and IEEE 802.11 .......24
D.1. L2-LinkStatus ............................................24
D.2. L2-PoAList ................................................24
D.3. L2-PoAFound ..............................................24
D.4. L2-PoALost ................................................25
D.5. L2-LinkUp ................................................25
D.6. L2-LinkDown ..............................................25
D.7. L2-LinkStatusChanged ......................................25
D.8. L2-LinkConnect ............................................26
D.9. L2-LinkDisconnect ........................................26
Appendix E. Implementation and Evaluation of the Proposed
Model ................................................261. Introduction 🌈
wireless networks have been absolutely blowing up 📈📱, and they're totally different from wired ones 💀. radio conditions, connectivity and available bandwidth are always changing 🌊. so for efficient communication, a protocol layer needs to know about or use other layers' control info 🧠
Mobile IPv4 [2] and Mobile IPv6 [3] are already standardized for mobile nodes 📱. there are also proposals for seamless handovers in IPv6, like Fast Handovers for Mobile IPv6 (FMIPv6) [4] and Hierarchical Mobile IPv6 (HMIPv6) [5] 🦋. the tricky bit with FMIPv6 is that the network layer has to know ahead of time that a handover is coming from the link layer, to get seamless handovers 😤. but since each layer is designed independently, that info exchange usually isn't available 💔
so this doc defines nine kinds of L2 abstractions, written as "primitives", to get fast handovers going at the network layer 🚀. it's called "L3-driven fast handovers" because the network layer is what starts the L2 and L3 handovers using those primitives ✨
IEEE 802.21 [6] also defines some services that use L2 info 📡. but for ease of implementation and deployment, the primitives here only use info the mobile node already has 📲. IEEE 802.21 [6] instead brings in an information server on the network to give the mobile node network-related info, like a global network map 🗺️
this document represents the consensus of the MobOpts Research Group 🤝. it's been reviewed by Research Group members who are active in this specific area of work 👩💻
2. Terminology 🍓
this doc uses the following terms:
L3-Driven Fast Handover: the handover mechanism that the network layer starts on a mobile node 🧚. because it lets L3 prepare for handover before the L2 handover starts on the mobile node, it can reduce packet loss during a handover 🫧. this mechanism needs L2 info as a trigger for the handover procedure ⚡
PoA: the point of attachment of a mobile node, like an access point in IEEE 802.11 networks [7] 📶
Primitive: a unit of info sent from one layer to another 💌. there are four classes of primitives: Request, Confirm, Indication, and Response 💜. one or more classes of a primitive get exchanged, depending on the type of primitive 🔁
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] 📜
3. Primitives for L2 Abstractions 🎀
every layer offers its services as primitives 🎁. four classes of primitives are defined, shown in Figure 1 🖼️. a Request is issued by the layer that wants services or info from another layer, and a Confirm is the acknowledgment of that request ✅. an Indication is the notification of info sent to the layer that asked for the service, and a Response is the acknowledgment of the Indication 💬. in this architecture, communication between layers is symmetrical 🪞
------------------------- -----------------------------
Request Response
|| /\ /\ ||
Layer N || || || ||
------------||------||--- -------||------||------------
|| || || ||
\/ || || \/
Layer N-m Confirm Indication
------------------------- -----------------------------
Figure 1: Interaction Model between Layersa primitive has five fields: protocol layer ID, protocol ID, primitive class (Request, Response, Indication, or Confirm), primitive name, and parameters 📦. the protocol layer ID says which layer the primitive should go to, like Layer 2 or Layer 3 🎯. the protocol ID says which protocol entity it should go to, like IEEE 802.11 [7] or IEEE 802.3 [8] 🔌
for unified L2 abstractions for L3-driven fast handovers, there are three usages of primitives, as described below 💅
Type 1. To provide L2 information to upper layers immediately 🏃♀️: this type gives upper layers L2 info right away. the Request and Confirm classes of primitives MUST be exchanged for this interaction. the Request is an acquisition request for the L2 info, and the Confirm is the answer 💁♀️
Type 2. To notify upper layers of L2 events asynchronously 🔔: this type tells upper layers about L2 events whenever they happen, not in lockstep. the Request, Confirm, and Indication classes of primitive MUST be exchanged, and the Response class MAY be exchanged for the interaction. the Request and Confirm are just for registration. when an event occurs, the Indication gets asynchronously delivered to the upper layer 📬
Type 3. To control L2 actions from upper layers 🕹️: this type lets upper layers control L2 actions. the Request and Confirm classes of primitives MUST be exchanged for this interaction. the Request is a request for an operation, and Ack or Nack comes back right away as the Confirm 🙌
a protocol entity can register primitives at any time by exchanging the Request and Confirm messages that include the fields above 📝. when the registered event happens, the Indication and Response messages get exchanged too 🎉
how messages get exchanged between protocol entities is beyond the scope of this document 🙃. any info-exchange method between layers, like the work in [10], can be used 🧩
the timing for sending an Indication primitive is also beyond the scope of this document 🕰️. for example, a layer 2 event gets generated when layer 2 status changes, and that depends on how things like scanning algorithms are implemented 🔍
to be continued in part 2 💖
4. Definitions of Primitives ✨
okay bestie, so to get and swap L2 info, we've got a whole set of primitives 💅 Appendix C has the mapping between these L2 primitives and the ones in IEEE 802.11 [7] and IEEE 802.16e [9], so you can see how they line up 🎀
4.1. L2-LinkStatus (Type 1) 🌸
the L2-LinkStatus.request primitive gets sent down to the link layer whenever an upper layer wants the current info on a link 👀 it carries the Network Interface ID parameter (see Section 5.1). then the L2-LinkStatus.confirm primitive comes back with three parameters: Network Interface ID, PoA, and Condition. PoA and Condition are the ones that tell you the current status of the link between the mobile node and a PoA 💜
4.2. L2-PoAList (Type 1) 🦋
the L2-PoAList.request primitive is sent to the link layer when an upper layer wants a list of the candidate PoAs. it contains the Network Interface ID parameter. the L2-PoAList.confirm primitive then returns with the Network Interface ID parameter and the PoA List parameter, and PoA List is literally the list of candidate PoAs 🧚
4.3. L2-PoAFound (Type 2) 🔥
the L2-PoAFound.indication primitive is handed up to an upper layer asynchronously whenever new PoAs get detected. it carries Network Interface ID and PoA List, and that PoA List holds info on the new PoAs the mobile node found ✨
but here's the thing: to get these notifications, you need to register first 🫶 that's done with the L2-PoAFound.request primitive and the L2-PoAFound.confirm primitive, and you have to do it in advance. the L2-PoAFound.request has two parameters, Network Interface ID and Enable/Disable. Enable/Disable shows whether the notification function is turned on. if the registration works, the L2-PoAFound.confirm comes back with the Network Interface ID parameter and the Ack parameter 💖
4.4. L2-PoALost (Type 2) 🙈
the L2-PoALost.indication primitive is handed up asynchronously to an upper layer when a PoA that was on the candidate list disappears 😭 it carries Network Interface ID and PoA List, and this time PoA List contains the PoAs that vanished from the candidate list. the registration process uses the L2-PoALost.request and L2-PoALost.confirm primitives, and it's basically the same deal as L2-PoAFound above 🌈
4.5. L2-LinkUp (Type 2) 🎀
the L2-LinkUp.indication primitive is handed up asynchronously to an upper layer when a new link gets connected and IP packets can actually go through it 🦋 as described in RFC 4957 [12], what "link is connected" means depends on the link type. for example, in infrastructure mode in IEEE 802.11 [7] (WiFi), this primitive fires when an association to an access point is established 🧚
it carries the Network Interface ID parameter and the PoA parameter. the L2-LinkUp.request primitive contains Network Interface ID and Enable/Disable for registration. when the registration succeeds, the L2-LinkUp.confirm primitive comes back with Network Interface ID and Ack 💅
4.6. L2-LinkDown (Type 2) 💀
the L2-LinkDown.indication primitive is handed up asynchronously to an upper layer when an existing link gets disconnected and IP packets can't go through it anymore 😭 the registration processing is exactly the same as L2-LinkUp above, so no new drama 🍓
4.7. L2-LinkStatusChanged (Type 2) 🌸
the L2-LinkStatusChanged.indication primitive is handed up asynchronously to an upper layer when the status of a link changes ⭐ this notification has three parameters: Network Interface ID, PoA, and Condition. the PoA parameter tells you which attachment point's link quality changed 👀
for the registration processing, the L2-LinkStatusChanged.request primitive carries Network Interface ID, Enable/Disable, and Condition. and Condition here is the event type plus the threshold for the Indication, so it's doing a lot 🔥
4.8. L2-LinkConnect (Type 3) 👑
the L2-LinkConnect.request primitive is sent to the link layer when an upper layer needs to set up a new link to a specific PoA 🫶 it carries Network Interface ID and PoA. this operation only starts after the link layer returns the L2-LinkConnect.confirm primitive with Ack ✨
4.9. L2-LinkDisconnect (Type 3) 🧚
the L2-LinkDisconnect.request primitive is sent to the link layer when an upper layer needs to tear down an existing link to a specific PoA 💔 it carries Network Interface ID and PoA. this operation begins after the link layer returns the L2-LinkDisconnect.confirm primitive with Ack 🦋
5. Definitions of Static Parameters 🎀
these are the static parameters, and once they're configured they mostly stay the same during communication 🧊 the following parameters get transferred as part of primitives 💜
5.1. Network Interface ID 🌈
the Network Interface ID parameter uniquely identifies the network interface in the node 🔥 the syntax is implementation-specific, like a name, an index, or a unique address assigned to each interface ✨ it also holds the network interface type, which tells you what kind of technology the interface uses, such as IEEE 802.11a/b/g [7], Third Generation Partnership Project (3GPP), and so on 🛜 this parameter is required in all primitives 🫶
6. Definitions of Dynamic Parameters 🌸
these are the dynamic parameters, and their values change frequently while communication is happening 😤 they also get transferred as part of primitives 🦋
6.1. PoA (Point of Attachment) 📍
the PoA parameter uniquely identifies the PoA 💖
6.2. Condition 📶
the Condition parameter has two sub-parameters: available bandwidth and link quality level 💅 these are abstracted info that show the current quality of service, and the abstraction algorithms depend on the hardware and software implementation 🛠️
the useful range of link quality is split into five levels, in descending order: EXCELLENT, GOOD, FAIR, BAD, and NONE 🌈 the quality levels of one L2 device don't depend on the ones for other devices 👯 but honestly, making decisions based on these metrics is error prone, and it's not guaranteed to pick the optimal link, so be careful 🙈 an example of the thresholds among the five levels in IEEE 802.11 [7] is in Appendix E 🎀
6.3. PoA List 📋
the PoA List parameter is made of arbitrary couples of two sub-parameters: PoA and Condition. it shows a list of PoAs and their conditions ✨
6.4. Enable/Disable 🔔
the Enable/Disable flag turns event notification on or off 🔛 when an upper layer needs notifications, the Request primitive with Enable gets sent to the link layer as registration. when an upper layer needs no more notifications, the Request primitive with Disable gets sent 🫡
6.5. Ack/Error ✅
when an upper layer requests some notifications, the link layer receives and confirms that Request 👂 if the Request is valid, the Confirm primitive with Ack goes up to the upper layer. if it's invalid, the Confirm with Error goes up instead 💀
7. Architectural Considerations ✨
okay so [RFC 4907] [11] is the one that digs into how link indications fit into the Internet Architecture 🏗️ and this section covers the architectural considerations mentioned in Section 2 of RFC 4907. let's go!! 🦋
- Proposals should avoid use of simplified link models in circumstances where they do not apply.
the info in each layer should be abstracted before it gets sent to another layer 🎀. like, in IEEE 802.11 [7], the Received Signal Strength Indicator (RSSI), the number of retransmissions, and whether there's an association between the mobile node and the access point all get used so the link layer indications can adjust to different environments or situations 🌸. the thresholds needed for some link indications come from empirical study, so they're not just vibes 📊.
in the conventional protocol-layering model, the Protocol Entity (PE) is the entity that processes a specific protocol. our proposal introduced the Abstract Entity (AE) to get link independency for the link indications 💅. an AE and a PE make a pair ✨. the AE takes the PE-dependent info and abstracts it into PE-independent info, which is so iconic 👑.
Figure 2 shows AEs and PEs using primitives 🧚.
---------------------------------------------------------
----------=========== ----------===========
| |[ ] | |[ ]
| PE |[ AE ] | PE |[ AE ]
| |[ ] | |[ ]
----------=========== ----------===========
Layer N || /\ || /\
------------||---||-------------------||---||------------
Request|| || Response|| ||
|| || || ||
|| || || ||
|| ||Confirm || ||Indication
------------||---||-------------------||---||------------
\/ || \/ ||
----------=========== ----------===========
| |[ ] | |[ ]
| PE |[ AE ] | PE |[ AE ]
| |[ ] | |[ ]
----------=========== ----------===========
Layer N-m
---------------------------------------------------------Figure 2: AE and PE with Primitives
- Link indications should be clearly defined, so that it is understood when they are generated on different link layers.
to make the link info/indications clear 🔍, our proposal defines 4 types of primitives: Request/Confirm and Indication/Response, as described in Section 3 🫶. the Request is used to get info from another layer. the Confirm is the reply to the request and it includes the requested info. the Indication gets generated when a particular event happens. the Response is the reply to the indication. period 💜.
in our proposal on IEEE 802.11b [7], L2-LinkUp is defined as the status where an association to the Access Point (AP) is established, and L2-LinkDown is defined as the status where an association to the AP is not established 🌈. L2-LinkStatusChanged gets generated when the link quality goes below the predefined threshold 📉. since the RSSI and the number of retransmissions are used to abstract and evaluate the link quality, L2-LinkStatusChanged represents the link quality in both directions 🔁. it should use an average of the RSSI or the number of retransmissions damped for one second or more to cope with transient link conditions ⏱️. the vibe is calm, steady, no panicking over blips 🧘♀️.
- Proposals must demonstrate robustness against misleading indications.
RSSI changes a LOT even when the mobile node is standing still, according to the measurements in our experiments 😭. so our proposal uses the RSSI, the number of retransmissions, and the existence of an association to calculate the link status, as described above 🧮. in our experiments there were some "ping-pong" handovers between two APs 🏓. those ping-pong handovers could be reduced by detecting the most suitable AP by L2-LinkStatus when L2-LinkStatusChanged is notified 🎯. the use of L2 indications is related to parameter thresholds that trigger handover. these thresholds vary based on the deployment scenario and, if not configured properly, could lead to misleading indications 🙈. not me being worried about misconfigured thresholds 💀.
- Upper layers should utilize a timely recovery step so as to limit the potential damage from link indications determined to be invalid after they have been acted on.
the proposed L3-driven handover described in Appendix E uses the L2-LinkStatusChanged indication as the trigger for starting handover 🚀. L2-LinkStatusChanged gets indicated when the link quality goes below a specific threshold. this indication is not canceled even if the link quality goes back up soon 😤. as described above, L2-LinkStatus can be used to detect the most suitable AP 🎯. the IP layer can cancel a handover if it finds that the current AP is the most suitable one by using L2-LinkStatus when L2-LinkStatusChanged is notified. main character energy for the IP layer, honestly 👑.
- Proposals must demonstrate that effective congestion control is maintained.
since this mechanism is coupled to the IP layer, and not directly to the transport layer, the proposed mechanism does not directly affect congestion control 🌊. no drama here, bestie 🫶.
- Proposals must demonstrate the effectiveness of proposed optimizations.
in IPv6 mobility, the L3-driven handover mechanism using link indications can dramatically reduce gap time due to handover ⚡. the L3-driven handover mechanism needs the L2-LinkStatusChanged indication to predict disconnection 🔮. but L2-LinkStatusChanged is sometimes not trusted, because it's difficult to abstract the link quality 😬. invalid L2-LinkStatusChanged may cause redundant handover 🔁. a handover mechanism using only L2-LinkUp/L2-LinkDown can also reduce gap time, just more modestly 🍓. an example of an implementation and evaluation of the L3-driven handover mechanism is described in Appendix E 📖.
- Link indications should not be required by upper layers in order to maintain link independence.
our proposal does not require any modifications to the transport and upper layers 🙌. the upper layers are untouched and happy 🎀.
- Proposals should avoid race conditions, which can occur where link indications are utilized directly by multiple layers of the stack.
since our proposal defines the link indications only to the IP layer, race conditions between multiple layers never occur 🏁. one layer, one vibe, zero chaos ✨.
- Proposals should avoid inconsistencies between link and routing layer metrics.
our proposal does not deal with routing metrics 🗺️. not our lane, bestie 💅.
- Overhead reduction schemes must avoid compromising interoperability and introducing link-layer dependencies into the Internet and transport layers.
as described above, the link indications in our proposal are abstracted to info that's independent of link types 🫧. that's how we cut the gap time due to a handover, and the ordinary host can execute handover without using the link indications defined in our proposal 🧚. interop stays intact, periodt 💜.
- Proposals advocating the transport of link indications beyond the local host need to carefully consider the layering, security, and transport implications.
in general, implicit signals are preferred to explicit transport of link indications, since they add no new packets in times of network distress 🆘, operate more reliably in the presence of middle boxes such as NA(P)Ts (Network Address (Port) Translations) 📦, are more likely to be backward compatible 🔙, and are less likely to result in security vulnerabilities 🔐. implicit signals really said "less is more" 🤍.
our proposal does not define the exchange of link indications between nodes 🙅♀️.
8. Security Considerations 💀
okay the security part is SERIOUS, bestie 😭. RFC 4907 [11] discusses the role and issues of link indications within the Internet Architecture, and this section discusses the security considerations mentioned in Section 4 of RFC 4907 🔒.
- Spoofing
the proposed primitives suffer from spoofed link-layer control frames 🎭. for example, if a malicious access point is set up and spoofed beacon frames are transmitted, L2-PoAFound.indication is generated in the mobile node 🚨. as a result, the mobile node may establish an association with the malicious access point by an L2-LinkConnect.request 😱. nope, nope, nope 🙅♀️.
- Indication validation
transportation of the link indications between nodes is not assumed, so this consideration is beyond the scope of our proposal 🫠. not our problem to solve here 🤷♀️.
- Denial of service
since this proposal does not change link-layer protocols, no more insecurity is added to a particular link-layer protocol ✅. however, the proposed primitives suffer from denial-of-service attacks by spoofed link-layer frames 💥. for example, L2-PoAFound.indication and L2-PoALost.indication may frequently be generated alternately if a malicious access point frequently transmits control frames that indicate strong RSSI and weak RSSI alternately 🎢. that's a chaotic ride, not a vibe 😵💫.
9. Acknowledgements 🌸
the authors gratefully acknowledge the contributions of Jukka Manner, Christian Vogt, and John Levine for their review 🫶💖. the real MVPs 👑.
10. References 📚
10.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 📖
10.2. Informative References 📚
- [2] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002.
- [3] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [4] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
- [5] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
- [6] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE P802.21/D02.00, September 2006.
- [7] IEEE, "802.11-2007 IEEE Standard for LAN/MAN - Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", 2007.
- [8] IEEE, "802.3, 2000 EDITION ISO/IEC 8802-3:2000 (E) Information Technology - LAN/MAN - Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", 2000.
- [9] IEEE, "802.16e-2005 & 802.16/COR1 Part 16: Amendment for Physical & Medium Access Control Layers for Combined Fixed & Mobile Operation", 2006.
- [10] Gogo, K., Shibu, R., and F. Teraoka, "An L3-Driven Fast Handover Mechanism in IPv6 Mobility", In Proc. of International Symposium on Applications and the Internet (SAINT2006) Workshop in IPv6, February 2006.
- [11] Aboba, B., Ed., "Architectural Implications of Link Indications", RFC 4907, June 2007.
- [12] Krishnan, S., Ed., Montavont, N., Njedjou, E., Veerepalli, S., and A. Yegin, Ed., "Link-Layer Event Notifications for Detecting Network Attachments", RFC 4957, August 2007.
- [13] Ishiyama, M., Kunishi, M., Uehara, K., Esaki, H., and F. Teraoka, "LINA: A New Approach to Mobility Support in Wide Area Networks", IEICE Transactions on Communication vol. E84-B, no. 8, pp. 2076-2086, August 2001.
Appendix A. Example Scenario 🎀
Okay so here's an example, bestie 🦋. The picture below shows the L3-driven fast handover mechanism using the L2 triggers on a mobile node (MN). It's giving message-passing choreography ✨
L2 L3
| |
|<----------LinkUP.req-----------|
|-----------LinkUP.cnf---------->|
|<-----LinkStatusChanged.req-----|
|------LinkStatusChanged.cnf---->|
= =
| |
Low |
Signal---LinkStatusChanged.ind---->|
| |
|<----------PoAList.req----------|
|-----------PoAList.cnf------>Handover
| Preparation
|<-------LinkConnect.req---------|
L2 Handover--LinkConnect.cnf-------->:
: :
: :
finish---------LinkUp.ind----->L3 Handover
| finish
| |
L2: Link Layer on MN
L3: Network Layer on MN
req: Request
cnf: Confirm
ind: Indication
Figure 3: L3-Driven Fast Handover MechanismFirst, L3 issues LinkUp.request so it gets a LinkUp.indication when the link becomes available. L3 also issues LinkStatusChanged.request so it hears LinkStatusChanged.indication when the link quality drops below the threshold. 🔥
At the start of the L3-driven handover, L2 notices the radio signal strength going down, so it sends L2-LinkStatusChanged.indication to L3. L3 gets itself ready (for example Care-of Address (CoA) generation, Duplicate Address Detection (DAD), Neighbor Discovery (ND) cache creation, and routing table setting) and sends L2-PoAList.request to L2 if a list of access points is needed. Main character prep energy 💅
If L3 decides to handover based on some rules, it sends L2-LinkConnect.request with some parameters about candidate access points to ask L2 for a handover. The L2 handover starts after L2 sends L2-LinkConnect.confirm to L3. When the L2 handover finishes, L2 sends L2-LinkUp.indication to tell L3. Finally, L3 performs the handover (for example, sending a Binding Update (BU)). ✨
One of the important features of the L3-driven fast handover using primitives is that L3 handover preparation can be done during communication. So, it can reduce disruption time during handover. 🌈
Appendix B. Example Operation for FMIPv6 🧚
Two scenarios of L3-driven fast handover for FMIPv6 exist, bestie 💜 Scenario 2 is different from scenario 1 in the timing of when some messages get sent.
B.1. Example Operation-1 for FMIPv6
Figure 4 shows the predictive mode of FMIPv6 operation with an L3-driven link-switching mechanism. 🦋
MN-L2 MN-L3 PAR-L3
| | |
AP<----------PoAList.req----------| |
Scan----------PoAList.cnf--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
|----------PoAFound.ind--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
| | |
~ ~ ~
| | |
Low | |
Signal---LinkStatusChanged.ind---->| | NAR-L3
| |-----FBU---->| |
| | |----HI---->|
| | |<--HAck----|
| |<----FBack---| |
|<-------LinkConnect.req---L3 Handover | |
L2 Handover--LinkConnect.cnf-------->: |
: : |
: : |
finish---------LinkUp.ind---------->: |
| :-----------FNA---------->|
| finish<======packets=========|
| | |
MN-L2 : Link Layer on Mobile Node
MN-L3 : Network Layer on Mobile Node
PAR-L3 : Network Layer on Previous Access Router
NAR-L3 : Network Layer on New Access Router
req : Request
cnf : Confirm
ind : Indication
RtSolPr : Router Solicitation for Proxy
PrRtAdv : Proxy Router Advertisement
FBU : Fast Binding Update
FBack : Fast Binding Acknowledgment
FNA : Fast Neighbor Advertisement
HI : Handover Initiate
HAck : Handover Acknowledge
Figure 4: L3-Driven Fast Handover Mechanism with FMIPv6 Scenario 1When MN establishes link connectivity to PAR, it performs router discovery. MN sends an RtSolPr message to PAR to resolve the access point identifiers to the subnet router information. To send RtSolPr, MN discovers one or more access points by sending L2-PoAList.request to the link layer. As a response to L2-PoAList.request, L2-PoAList.confirm returns with a "PoA List" parameter that contains identifiers and conditions of nearby access points. After the initial AP discovery, L2-PoAFound.indication with "PoA List" is also sent from the link layer when one or more access points are discovered. 🌸
When the link layer of MN detects that radio signal strength is dropping, it sends L2-LinkStatusChanged.indication to the network layer. Then MN sends the FBU message to PAR as the beginning of the L3 handover procedure. The NCoA required for the FBU message is determined according to the MN's policy database and the received PrRtAdv message. As a response to the FBU message, MN receives the FBack message and then immediately switches its link by L2-LinkConnect.request with the specific "PoA" parameter. The handover policy of the MN is outside the scope of this document. 🙈
After L2 handover, the link layer of the MN sends L2-LinkUp.indication to the network layer. MN immediately sends the FNA message to the New Access Router (NAR). The NAR will send tunneled and buffered packets to MN. 💀
B.2. Example Operation-2 for FMIPv6
Figure 5 shows the predictive mode of FMIPv6 operation with an L3-driven link-switching mechanism. Same vibe, different timing 🫶
MN-L2 MN-L3 PAR-L3
| | |
AP<----------PoAList.req----------| |
Scan----------PoAList.cnf--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
|----------PoAFound.ind--------->| |
| |---RtSolPr-->|
| |<--PrRtAdv---|
| | |
~ ~ ~
| | |
Low | |
Signal---LinkStatusChanged.ind---->| | NAR-L3
| |-----FBU---->| |
|<-------LinkConnect.req---L3 Handover | |
L2 Handover--LinkConnect.cnf-------->: | |
| | |----HI---->|
| | |<--HAck----|
| | <-FBack-|---FBack-->|
| |<----FBack---------------|
: : |
finish---------LinkUp.ind---------->: |
| :-----------FNA---------->|
| finish<======packets=========|
| | |
MN-L2 : Link Layer on Mobile Node
MN-L3 : Network Layer on Mobile Node
PAR-L3 : Network Layer on Previous Access Router
NAR-L3 : Network Layer on New Access Router
req : Request
cnf : Confirm
ind : Indication
RtSolPr : Router Solicitation for Proxy
PrRtAdv : Proxy Router Advertisement
FBU : Fast Binding Update
FBack : Fast Binding Acknowledgment
FNA : Fast Neighbor Advertisement
HI : Handover Initiate
HAck : Handover Acknowledge
Figure 5: L3-Driven Fast Handover Mechanism with FMIPv6 Scenario 2Unlike scenario 1, MN in scenario 2 sends LinkConnect.req from the network layer to the link layer after MN sends the FBU message. As PAR sends the FBack messages not only to PAR's subnet but also to NAR's subnet, MN can get the FBack message sent by PAR through NAR, and then it moves to NAR. The timing is the whole plot twist, bestie 🍓👑
B.3. Experiment ✨
okay so we actually built FMIPv6 and the proposed L2 primitives on FreeBSD-5.4 💻 Figure 6 shows our test network. MN is connected to the access routers over IEEE802.11a wireless LAN, and it moves from PAR to NAR 🦋
|
+--+---+
|Router|
+--+---+
| 100BaseTX
---+--------+---------+---------+---------+------------
| | | |
+--+--+ +--+--+ +--+--+ +--+--+
| PAR | | NAR | | HA | | CN |
+-----+ +-----+ +-----+ +-----+
| |
IEEE802.11a IEEE802.11a PAR, NAR: nexcom EBC
|Channel 7 |Channel7 MN: ThinkPad X31
OS: FreeBSD-5.4
| | KAME/SHISA/TARZAN
+-----+ +-----+
| MN | -------> | MN |
+-----+ +-----+
Figure 6: Test NetworkScenario 1 was the one we used since it was more stable than scenario 2 🥹 Once MN got L2-LinkStatusChanged.indication, its L3 sent the FBU message and then received the FBack message back. It took 20ms from the FBU going out to the FBack coming in ⏱️ After receiving FBack, L3 of MN issued L2-LinkConnect.request to L2. When the L2 handover finished, L3 got L2-LinkUp.indication from L2. The L2 handover itself took 1ms, which is literally so fast 🙈 Next, MN sent the FNA message to NAR. When NAR got the FNA message, it started forwarding packets to NM. ICMP echo request packets were sent at 10ms intervals, and it was observed that zero or one ICMP echo reply packet was lost during a handover 💅
MN PAR NAR
| | |
|----- RtSolPr --->| |
|<---- PrRtAdv ----| |
| | |
+--- |------ FBU ------>| |
| | |------- HI ------>|
20ms| | | |
| | |<----- HAck ------|
| | | |
+--- |<-------------- FBack -------------->|
| | |
+-- disconnect | |
| 1ms| | |
| connect | |
8-10ms| | | |
| 7ms| | |
| | | |
| +----- FNA -------------------------->|
+-- |<------------------------ deliver packets
| | |
Figure 7: Measured ResultsAppendix C. Example Mapping between L2 Primitives and the Primitives in IEEE 802.11 and IEEE 802.16e ✨
okay this part is the mapping glow-up 🫶 It shows example mapping between the L2 primitives and the primitives in IEEE 802.11 [7] and IEEE 802.16e [9] in Table 1. Table 1 is in a code block so nothing gets scrambled 💖
+-------------------+----------------------+------------------+
| L2 Primitive | IEEE802.11 | IEEE802.16e |
+-------------------+----------------------+------------------+
| L2-LinkStatus | PMD_RSSI | Available |
| | | |
| | PMD_RATE | |
| | | |
| L2-PoAList | MLME-SCAN | M_ScanScheduling |
| | | |
| | | M_Scanning |
| | | |
| L2-PoAFound | MLME-SCAN | M_Neighbor |
| | | |
| | | M_Scanning |
| | | |
| L2-PoALost | MLME-SCAN | M_Neighbor |
| | | |
| | | M_Scanning |
| | | |
| L2-LinkUp | MLME-ASSOCIATE | M_Registration |
| | | |
| | MLME-AUTHENTICATE | |
| | | |
| L2-LinkDown | MLME-DEASSOCIATE | M_Ranging |
| | | |
| | MLME-DISAUTHENTICATE | |
| | | |
| L2-StatusChanged | PMD_RSSI | M_Ranging |
| | | |
| | | M_ScanReport |
| | | |
| | | M_Scanning |
| | | |
| L2-LinkConnect | MLME-JOIN | M_MACHandover |
| | | |
| | MLME-ASSOCIATE | M_HOIND |
| | | |
| | MLME-REASSOCIATE | |
| | | |
| | MLME-AUTHENTICATE | |
| | | |
| L2-LinkDisconnect | MLME-DISASSOCIATE | M_Management |
| | | |
| | MLME-DEASSOCIATE | (Deregistration) |
+-------------------+----------------------+------------------+
Table 1: Mapping between L2 Primitives and the Primitives in
IEEE 802.11 and IEEE 802.16eAppendix D. Example Mapping of Primitives and IEEE 802.11 🎀
this appendix is the IEEE 802.11 deep dive, and it is SO good 🤓 It shows examples of the mapping between primitives and IEEE 802.11 [7] parameters.
D.1. L2-LinkStatus
most of the L2-LinkStatus parameters are about how the network-interface hardware is configured 🔧 The operating system and the device-driver module can easily collect that info. But to create the "Condition" parameter, the MN has to keep statistics and parameters about the current wireless environment, which is a lot ngl 😭
there are two sub-parameters of "Condition": available bandwidth and link quality level 🌈 The available bandwidth of the current PoA can be worked out by keeping track of the transmission rate indication and the frame-transmission statistics every time a frame is sent. A link quality level gets updated by tracking these every time a frame is received: Received Signal Strength Indicator (RSSI), transmission/reception rate indication, transmit/receive latency, bit-error rate, frame-error rate, and noise level. The link quality level is split into five levels: EXCELLENT, GOOD, FAIR, BAD, and NONE, in descending order 📶 Some parameters can be managed by setting thresholds from software. When a parameter crosses its threshold, an interrupt is generated for the software ⚡
D.2. L2-PoAList
in IEEE 802.11 networks, L2-PoAList returns the detected APs whose quality level is over the specified threshold for PoA candidates (that's the "PoA List" parameter) 📋 So an MN should always keep a database of available access points, updated from beacon frames, probe response frames, and all frames. This AP database is managed by looking at time, number of frames, and signal strength. Some network-interface hardware can only notify the operating system when the event you want happens, once a threshold is set from software 🔔 And the MN can also send a probe request frame for access point discovery, if needed 🔍
D.3. L2-PoAFound
in IEEE 802.11 networks, L2-PoAFound gets notified when new PoAs whose link quality level is over the specified threshold are detected, either by listening to beacons or by scanning APs 👀 If the received frame (mainly the beacon or the probe response) is not in the AP database from Appendix D.2, then the link layer creates L2-PoAFound.indication.
for example, if the threshold of link quality level given in L2-PoAFound.request is GOOD, then L2-PoAFound.indication gets created and sent up to the upper layer when the PoA's link quality becomes better than GOOD 🌸
D.4. L2-PoALost
in IEEE 802.11 networks, L2-PoALost gets notified when an AP that's on the list of candidate APs is lost, whether by listening to beacons or by scanning APs 😬 If the entry in the AP database from Appendix D.2 expires, or the link quality level drops under the threshold, then the link layer creates L2-PoALost.indication. To work out the link quality level, the signal strength of the received frame (mainly the beacon or the probe response) can be used 📉 For example, if the threshold of the link quality given by L2-PoALost is BAD, then L2-PoALost.indication gets created and sent up to the upper layer when the PoA's link quality becomes worse than BAD 💔
D.5. L2-LinkUp
in IEEE 802.11 networks, L2-LinkUp gets notified when an association or reassociation event happens 🤝 When that happens, MN receives the association response frame or the reassociation response frame. Right after receiving it, the link layer creates L2-LinkUp.indication ✨
D.6. L2-LinkDown
in IEEE 802.11 networks, L2-LinkDown gets notified when a disassociation event happens, or when no beacon is received for a certain amount of time 📡 When that happens, MN sends the disassociation frame to the AP, or the entry for that specific AP gets deleted from the AP database in Appendix D.2. By spotting these events, the link layer creates an L2-LinkDown.indication 🚪
D.7. L2-LinkStatusChanged
in IEEE 802.11 networks, L2-LinkStatusChanged gets notified when the radio signal strength of the connected AP drops below the specified threshold 📉🫠
D.8. L2-LinkConnect
in IEEE 802.11 networks, each AP is identified by its BSSID, and a group of APs in the same service set is identified by the SSID 🪪 When L2-LinkConnect is used to connect to a specific AP or a service set, the link layer should set the Basic Service Set Identifier (BSSID) or the Service Set Identifier (SSID). The channel should also be set at the same time, by searching the database in Appendix D.2 🔎 To connect to an AP, MN should be authenticated by that AP first. MN sends the authentication message to the AP, and then MN sends the association message to associate with it 🫶
D.9. L2-LinkDisconnect
in IEEE 802.11 networks, MN sends the disassociation message to the AP to disconnect 👋 When L2-LinkDisconnect is used to disconnect from the current AP, the link layer should send the disassociation message to the appropriate AP and stop data transmission 🛑
Appendix E. Implementation and Evaluation of the Proposed Model ✨
Okay bestie, this section is the glow-up 🦋 It's where the authors actually built the link indication architecture and tested it outdoors. Let's go 🚗💨
An IEEE 802.11a wireless LAN device driver got modified so it could hand out abstract link-layer information, using the primitives from Section 4. 💅 The modified driver keeps two AP lists. 🧚
The first list holds the device-dependent stuff: RSSI, retransmission count, various AP parameters, and a bunch of statistics. This info gets refreshed every time the device receives a frame, except for the AP parameters. Those only get updated when the frame is a management frame, and then they're updated from the parameters inside that frame. 📡
The second list holds the abstract info. It gets refreshed periodically using the device-dependent data. During abstraction, things like RSSI or the retransmission count get turned into the common indicator "link quality" 🌸 In their outdoor testbed, the RSSI thresholds between link quality levels were set like this:
EXCELLENT -- 34 -- GOODGOOD -- 27 -- FAIRFIAR -- 22 -- BADBAD -- 15 -- NONE
Now the slay part: L2-PoAList and L2-LinkStatus were built using only the abstract information 🙌 That means upper layers can see info about the current AP and the adjacent APs without caring what device is underneath. It's giving device independence fr fr. L2-PoAFound or L2-PoALost gets notified when link quality crosses a threshold going up or down during an abstract info update. If the current AP's link quality drops below a specific threshold, L2-LinkStatusChanged gets notified. L2-LinkUp or L2-LinkDown fires when an association with an AP gets established or destroyed. 💖
To make L2-LinkConnect and L2-LinkDisconnect work, the authors implemented functions that connect to or disconnect from a specified AP. Since only abstract info is needed to name the AP, the other layers never have to know anything about the device-dependent details. Iconic behavior 👑
Here's the testbed setup 🎀 There were eight Access Routers (ARs) placed 80-100m apart, and each AP was collocated with an AR. The link layer was IEEE 802.11a. Every AP used the same wireless channel, which means the testbed had eight wireless IPv6 subnets. The mobile node rode in a car going 30-40 km/h. When the link quality of the current AP dropped, the mobile node ran L3-driven handover, which is described in Appendix A. 🚘
An application called Digital Video Transport System (DVTS) ran on the mobile node and sent digital video at about 15Mbps through the wireless IPv6 subnet to the correspondent node. The correspondent node replayed the video it received 🎬
In this setup, the L2 handover took less than 1 msec. The mobility protocol Location Independent Networking in IPv6 (LIN6) [13] needed a few msecs for location registration. So the total gap time from handover was 3-4 msec. In most cases the replayed pictures weren't affected by the handover at all. Absolutely unbothered 😭🫶
Authors' Addresses 🧚
Here are the people behind this one, with all their contact deets 💌
Fumio Teraoka
Faculty of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: +81-45-566-1425
EMail: tera@ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Kazutaka Gogo
Graduate School of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: +81-45-566-1425
EMail: gogo@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Koshiro Mitsuya
Jun Murai Lab, Shonan Fujisawa Campus, KEIO University
5322 Endo
Fujisawa, Kanagawa 252-8520
Japan
Phone: +81-466-49-1100
EMail: mitsuya@sfc.wide.ad.jp
Rie Shibui
Graduate School of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: +81-45-566-1425
EMail: shibrie@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/
Koki Mitani
Graduate School of Science and Technology, KEIO University
3-14-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8522
Japan
Phone: +81-45-566-1425
EMail: koki@tera.ics.keio.ac.jp
URI: http://www.tera.ics.keio.ac.jp/Full Copyright Statement 💜
Copyright (C) The IETF Trust (2008). ✨
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at http://www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. 🎀
The legal disclaimer, verbatim because it's serious business 🙈
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🔥
The IETF doesn't take a side on whether any Intellectual Property Rights might cover the tech in this document, or whether licenses for them are even available. It also doesn't claim to have looked into any of that itself. If you want the rules on rights for RFC documents, check BCP 78 and BCP 79 📚
Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses that might be available, or the results of any attempt to get a general license for implementers or users, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🌈
The IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 🫶
That's the whole RFC, bestie! Period. 💅✨
📦 where this page comes from
- ietf: rfc5184 2008-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms