1. Proposal for Link State Establishment
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Proposal for Link State Establishment
Date:
Authors:
Notice: This document has been prepared to assist IEEE It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE
Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures < ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE Working Group. If you have questions, contact the IEEE Patent Committee Administrator at
M. Zhao (Intel Corp), et al.
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
July 2006
Abstract
This submission proposes an update to peer link establishment protocol.
M. Zhao (Intel Corp), et al.
John Doe, Some Company

3. Agenda Problems with existing protocol Problem statement
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Agenda
Problems with existing protocol
Problem statement
Proposed changes
Finite state automaton
M. Zhao (Intel Corp), et al.
John Doe, Some Company

4. Current Protocol (1) July 2006 Association Request (R1)
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Current Protocol (1)
Association Request (R1)
Association Response
Subordinate MP
Superordinate MP
M. Zhao (Intel Corp), et al.
John Doe, Some Company

5. Current Protocol (2) July 2006 R1 > R2? R1 > R2?
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Current Protocol (2)
Association Request (R1)
Association Request (R2)
R1 > R2?
R1 > R2?
Subordinate MP
Superordinate MP
Association Response
M. Zhao (Intel Corp), et al.
John Doe, Some Company

6. Design Problems July 2006 Unreliable communication
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Design Problems
Unreliable communication
Messages may get lost
Deadlock could happen
A message retransmission mechanism is needed to ensure peers come to the agreement of link establishment in the end of the protocol
In current design, it is not well defined
Bigger problem: no notion of link instance
Questions
How do I know that I’m exchanging messages to establish THIS link?
How do I know that the information I use for communication is fresh?
We need
An identifier to a particular link instance (“I’m establish THIS link with this peer MP”)
Binding between link instance and messages (“I don’t answer to messages that not for this link instance”)
Use random numbers for tie break
Collision could happen
No need to distinguish authenticator and supplicant roles at this point
M. Zhao (Intel Corp), et al.
John Doe, Some Company

7. Month Year
doc.: IEEE yy/xxxxr0
Example Failure Case #1
July 2006
Association Request (R1) R1
Association Request (R2) R2
timeout
Association Request (R1’)
R1’
R1 > R2?
Association Response
R1’ > R2?
Association Response
Superordinate MP
Superordinate MP
Two Superordinate MPs not a valid state in current protocol
Root problem: numbers used for tie break are transmitted separately.
M. Zhao (Intel Corp), et al.
John Doe, Some Company

8. Month Year
doc.: IEEE yy/xxxxr0
Example Failure Case #2
July 2006
Association Request (R1) R1
reboot
Association Response
Superordinate MP ??
Current protocol doesn’t fully specify what to do
M. Zhao (Intel Corp), et al.
John Doe, Some Company

9. Protocol Design Goals Deal with unreliable communication channel
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Protocol Design Goals
Deal with unreliable communication channel
No deadlock or livelock
Binding between identifiers and the link instance
Binding between link instance and the messages
M. Zhao (Intel Corp), et al.
John Doe, Some Company

10. Peer Link Establishment Overview
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Peer Link Establishment Overview
Three messages
Peer Link Open, Peer Link Confirm, Peer Link Close
Rules
Both peers can initiate the link establishment protocol
The peer link is established if and only if both peers send and receive Association Response messages
Link instance
Identifier <myId, peerId, myRa, peerRb>
myId and peerId: MAC addresses
myRa and peerRb: random numbers generated for this link instance
Enforce binding between link instance and messages
Peer Link Open (myId, peerId, Ra)
Peer Link Confirm (myId, peerId, Ra, Rb)
Peer Link Close (myId, peerId, Ra, Rb)
M. Zhao (Intel Corp), et al.
John Doe, Some Company

11. Example Protocol Execution (1)
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Example Protocol Execution (1)
Peer Link Open (A, B, Ra) A B
Peer Link Confirm (B, A, Rb, Ra)
Peer Link Confirm (A, B, Ra, Rb)
M. Zhao (Intel Corp), et al.
John Doe, Some Company

12. Example Protocol Execution (2)
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Example Protocol Execution (2)
Peer Link Open (A, B, Ra) A B
Peer Link Open (B, A, Rb)
Peer Link Confirm (A, B, Ra, Rb)
Peer Link Confirm (B, A, Rb, Ra)
M. Zhao (Intel Corp), et al.
John Doe, Some Company

13. Retransmission Mechanism
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Retransmission Mechanism
RetryTimer controls resend Peer Link Open if the local MP hasn’t heard anything from the peer MP within some period of time
RetryTimeout
Initially, 32 miliseconds
Standard backoff algorithm: timeout + (getRandom mod timeout)
MAX-REQS
MAX-REQS = 11
Has Pr(succeed) > % given the frame loss rate = 30%
CancelTimer controls graceful link close
Goes to holding state to handle messages that may be in fly
When CancelTimer expires, close the link and go back to IDLE
Handles Peer Link Close message the same way as does for Disassociate
Send and forget
M. Zhao (Intel Corp), et al.
John Doe, Some Company

14. Process Link Status Local system compute link status based on
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Process Link Status
Local system compute link status based on
payload in received Peer Link Open
local policy configuration
Push success/failure processing up to a higher level
The protocol always execute to complete
Use signalLinkStatus(peerId, myStatus, peerStatus) to inform higher layer
Higher level decision entity handles link status
CancelLink command may be issued to handle FAILURE cases
Dramatically simplifies the design
Not as efficient as letting the protocol handles status directly
M. Zhao (Intel Corp), et al.
John Doe, Some Company

15. Mesh Resource Block (MRB)
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Mesh Resource Block (MRB)
MRB stores variable values to represent the states for link establishment
<myId, peerId, Ra, Rb>
RetryCounter, RetryTimer, RetryTimeout
ResponseSentFlag, ResponseReceiveFlag
CancelFlag, CancelTimer
myStatus, peerStatus
MRB is initialized when the local system starts peer link establishment protocol
MRB is released when the local system goes back to IDLE state
M. Zhao (Intel Corp), et al.
John Doe, Some Company

16. Elements in Automaton States Events Actions 0. IDLE 1. LISTEN
Month Year
doc.: IEEE yy/xxxxr0
July 2006
Elements in Automaton
States
0. IDLE
1. LISTEN
2. OPEN_SENT
3. CONFIRM_SENT
4. ESTABLISHED
5. HOLDING
Events
CancelLink
PassiveOpen
ActiveOpen
CloseReceived
OpenReceived
ConfirmReceived
Timeout
Actions
closeSend
openSend
confirmSend
computeStatus
timerClear
timerSet
backoff(timeout)
allocateMRB
releaseMRB
getRandom
raiseException
signalLinkStatus
M. Zhao (Intel Corp), et al.
John Doe, Some Company

17. Finite State Automaton
Month Year
doc.: IEEE yy/xxxxr0
Finite State Automaton
July 2006 1 2 3 4 5
PassivOpen
CancelLink
ActiveOpen
OpenReceived
ConfirmReceived
CloseRceived
CloseReceived
Exceed MAX-REQS
CancelLink or ReceiveDisassociate or CancelTimer expires
RetryTimer expire
CancelLink or
0: IDLE 1: LISTEN : OPEN_SENT : CONFIRM_SENT : ESTABLISHED : HOLDING
M. Zhao (Intel Corp), et al.
John Doe, Some Company

18. Month Year
doc.: IEEE yy/xxxxr0
July 2006
Next Steps
Draft text describing the proposed update to the peer link establishment protocol is in doc 11-06/1106
We welcome any feedback and suggestions on this approach and welcome collaboration to improve the robustness of the peer link establishment protocol
M. Zhao (Intel Corp), et al.
John Doe, Some Company

19. Feedback? July 2006 Month Year doc.: IEEE 802.11-yy/xxxxr0
M. Zhao (Intel Corp), et al.
John Doe, Some Company