One document matched: draft-ietf-pppext-mppp-00.txt
PPP-Extension Working Group M. C. Chuah
Internet-Draft Bell Labs
Expires June 1st, 1999 D. Grosser
IBM Corporation
G. Rai
Lucent Technologies
Jacob Teplitsky
RABU
Lucent Technologies
Mobile PPP (MPPP)
draft-ietf-pppext-mppp-00.txt
Status Of This Memo
This document is an Internet-Draft. 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.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
This document describes a new feature for L2TP: it allows for a change
of LACs during the lifetime of a PPP session without the latency of
re-creating a new PPP session where possible. This feature is
specially useful for wireless data services where the foreign wireless
service provider (WSP) may be different than the user's home service
provider and where a user's mobility may result in a change of LAC
during an on-going PPP session. This proposal presents 3 different
methods of supporting this feature. The simplest method requires only
minor changes to both LACs and LNSs. However, it may give a larger
handover latency. The other two methods have shorter handover
latency and allow us to extend the L2TP session by an additional hop.
Table of Contents
1.0 Introduction .................................................2
1.1 Limitations of L2TP for wireless services.....................3
2.0 Overview of Mobile PPP........................................3
2.1 Simple AVP Approach ..........................................3
2.2 Independent Tunnel Approach...................................4
2.3 Concatenated Tunnel Approach..................................6
3.0 Service Model Issues .........................................7
3.1 Authentication ..............................................7
3.2 Accounting ...................................................7
4.0 Control Message Processing ...................................8
4.1 Newly Defined Control Message and AVPs........................8
4.1.1 Authentication Request.......................................8
4.1.2 Newly Defined AVPs...........................................8
Chuah expires June 1st, 1999 [Page 1]
Internet Draft Mobile PPP Nov 18th, 1999
4.1.2.1 User AVP..................................................9
4.1.2.2 Sequence Number AV .......................................9
4.1.2.3 A-LAC's Window AVP ......................................10
5.0 Security Issues .............................................10
6.0 Acknowledgments .............................................10
7.0 Contacts ....................................................10
8.0 References ..................................................11
Appendix 1: Using CTA in an Handover Scenario ......................11
Appendix 2: Transfer of Sequence Number During Handover ............12
Appendix 3: Multiple LNS Scenario ..................................12
1. Introduction
Serving PPP
IWF Server
-- -- ---------
MN <---> | | <------->| | <----> R ( Internet)
-- -- ---------
MN: Mobile Node
R: Router
IWF: Interworking Function
Fig 1 Typical wide area wireless access network architecture
Fig 1 shows the architecture of a typical wide area wireless
access network like CDMA, GSM, or TDMA. Current wireless standards
allow mobile nodes (MN) to dial up a PPP server to access the
internet. A link level tunnel is created between the serving
IWF and the PPP server. If the mobile node moves to another
serving IWF, link-layer messages are exchanged so that the tunnel
between the old serving IWF and the PPP server is torn down and a
new one set up between a new serving IWF and the PPP server.
If the mobile node moves further such that it has to change the
PPP server, then current wireless standards force a termination of
the PPP session. A new PPP session has to be negotiated between
the mobile node and the new PPP server. In addition, current
wireless standards do not provide virtual private networking
services to mobile nodes.
In current wireless architectures, the PPP server authenticates
mobile nodes using the negotiated PPP authentication protocol e.g.
CHAP. Since it is not aware of mobile node handovers in the
wireless network, it does not perform any authentication when a mobile
node changes its serving IWF.
In this document, we propose a mobile feature to the current IETF
L2TP protocol to provide wide area mobility to nodes without having to
renegotiate the PPP session during a handover. According to this
proposal, mobile nodes need only implement the TCP/IP/PPP stack with
no modifications. All current PCs and the future crop of hand held data
devices are expected to have this stack.
Chuah expires June 1st, 1999 [Page 2]
Internet Draft Mobile PPP Nov 18th, 1999
There are three methods to provide this mobile feature, namely
(a) Simple AVP Approach (SAA), (b) Independent Tunnel Approach
(ITA), and (c) Concatenated Tunnel Approach (CTA). Both the SAA and
ITA require changes to both LAC and LNS software but the CTA only
requires changes to the LAC. We list the advantages and disadvantages
of these 3 different approaches in later sections. We prefer CTA
because it provides end-to-end flow control for the 2-hop PPP
session and it requires less CPU processing compared to ITA.
This proposal is independent of the wireless access technologies. It
provides hooks to carry mobile node security credentials between
network access servers in a technology independent manner. It also
makes no assumptions about the methods by which wireless terminals
are identified or about the encryption and authentication methods
used by the wireless networks.
1.1 Limitations of L2TP for wireless services
The current L2TP draft [1] does not allow for a transfer of Network
Access Server (NAS) during an existing PPP session. In a cellular
environment, a change of NAS may occur during the lifetime of
a PPP session. A user may start a PPP session and move into another
service provider's coverage area which has a different NAS.
The current L2TP draft forces the user to drop the currrent PPP
session and renegotiate a new session. Instead of terminating the
existing PPP session and starting a new one which takes time and can
be expensive in high capacity, micro-cellular wireless networks, one
solution is to let the old NAS (LAC) transfer the PPP session to the
new NAS (LAC).
The current L2TP draft also does not allow mobile data users visiting
a foreign wireless ISP to use the wireless ISP for virtual
private networking services from an area where their home (wireless)
ISP is not in operation.
2.0 Overview of Mobile PPP
There are three methods for providing the mobile feature. These
methods differ in terms of their implementation complexity. The three
methods are (i) Simple AVP Approach (SAA), (ii) Independent Tunnel
Approach (ITA), and (iii) Concatenated Tunnel Approach (CTA).
2.1 Simple AVP Approach (SAA)
With the Simple AVP approach, both the existing LAC and LNS need to be
enhanced to process the User AVP, a newly defined AVP.
-------- ----------
| Old | Tunnel=2 | |
| LAC | ----------| LNS |
-------- callid=5 ---------
/
/
/ Tunnel=3, callid=1
---------
| New LAC |
---------
Chuah expires June 1st, 1999 [Page 3]
Internet Draft Mobile PPP Nov 18th, 1999
New LAC LNS Old LAC
Link
Msg 1 SCCRQ
---> ---------------------->
SCCRP (with Mobile AVP)
<--------------------
SCCCN
------------------->
ICRQ (with User AVP)
--------------------->
CDN
---------->
ICRP (with ACCM AVP, Proxy Auth AVP)
<--------------------
ICCN
------------------->
Fig 2 Simple AVP Approach
In Fig 2, we assume that the link layer message contains some subscriber
information. Such information allows the new LAC, via the help of
its local AAA server, to determine which LNS the new LAC should talk to.
We assume that when a tunnel is set up between a LAC and a LNS, the
LNS will respond with a Mobile AVP in its SCCRP message if it does support
the mobility feature. In addition, the LNS will interpret any ICRQ
with an attached User AVP as a possible signal of an handover for an
existing PPP call. Using the information provided in the User AVP, LNS
can use its local AAA server and its connection table to determine the
identity of the old LAC which the subscriber previously communicates
with.
If the LNS cannot accept the call handover, the LNS will send a CDN
message to the new LAC. If the LNS can accept the handover, the LNS
will send a Call Disconnect Notify (CDN) message to the old LAC. Next,
the LNS replies with an ICRP message to the new LAC as stated in [1].
To support the handover feature, the ACCM AVP, and possibly the Proxy
Authentication AVP need to be included in the ICRP message. We
assume that the sequence numbers will be re-initialized at the LNS
after the handover.
Note that we assume that the LAC does not initiate the teardown of
L2TP session (unless a relatively long inactivity timer times out).
Thus, there is no issue of LNS receiving a CDN message from the old
LAC due to the handover before receiving the ICRQ message from the new LAC.
The advantage of SAA is :
(a) it is very simple.
The disadvantages of SAA are:
(a) Both the LAC and LNS software need to be updated to recognise
the newly defined User AVP message.
(b) The handover latency may be long since the LAC may be located
within the WSP intranet while the LNS is located within the
ISP or corporate network far away.
(c) Roaming service may be limited to a smaller geographical area
because the LACs within the WSP intranets and the LNSs within a
corporate network do not trust one another unless there is a direct
agreement between different WSPs and the corporate network.
However, there may be cases where this approach is not secure or feasible. For
such cases, we may need to extend the PPP session to a 2-hop session.
A new entity called the Anchor LAC is introduced for the 2-hop
session.
2.2 Independent Tunnel Approach (ITA)
In the Independent Tunnel Approach, there are two L2TP data sessions
per PPP call: one between the Serving LAC and the Anchor LAC;
one between the Anchor LAC and LNS. To the Serving LAC, the Anchor
LAC looks like the LNS. To the LNS, the Anchor LAC looks like the
LAC. The flow control procedure for the two data sessions is
independent of one another. The Anchor LAC needs to provide a mapping
table to map the tunnel and call identities of one data session to
those of the related data session that belong to the same PPP call.
Thus, the Anchor LAC has to maintain 2N data sessions for N PPP calls
in ITA.
---------- --------
| Anchor | Tunnel=1 | LNS |
| LAC |-----------| |
--------- callid=3 --------
|
|
| Tunnel=3, callid=1
-------------
|Serving LAC |
-------------
Chuah expires June 1st, 1999 [Page 4]
Internet Draft Mobile PPP Nov 18th, 1999
S-LAC: Serving LAC A-LAC: Anchor LAC
Client S-LAC A-LAC LNS
Link Layer
Msg1 SCCRQ
---------> ---------->
SCCRP (with Mobile AVP)
<---------
SCCCN
------------>
ICRQ (with User AVP)
------------->
ICRP (with ACCM AVP, Proxy Auth AVP)
<-------------
ICCN Auth_Req (Optional)
-------------> ------->
ACK
<----------
Link Layer
Msg2
<---------
One hop to 2-hop Handover Scenario
Fig 3 Independent Tunnel Approach
In Fig 3, we assume that the mobile subscriber first establishes
a PPP call between the Anchor LAC and the LNS (tunnelid=1, callid=3).
Then, the mobile subscriber roams to the coverage area of another new
LAC (referred to as the Serving LAC). From the link-layer handoff
message, the Serving LAC discovers that there is an existing PPP call.
Thus, the Serving LAC sends an ICRQ message which contains a User AVP.
The Anchor LAC will first determine if this existing PPP call
requests for an extended hop or for a change of LAC. Such a
decision can be made with the help of the local AAA server and the
information contained in the User AVP. Next, the Anchor LAC decides
if this PPP call already has a 2-hop L2TP tunnel. If the Anchor LAC
determines that this existing PPP call needs an extended hop, it
will create an entry in its mapping table (MT) so that the L2TP
headers of all packets with (tunnelid=1,callid=3) from the incoming
interface can be swapped with an L2TP header with (tunnelid=3, callid=1)
at the outgoing interface. If a user-level re-authentication is
desired, the Anchor LAC can send an Authentication Request message
(an optional newly defined L2TP control message) to the LNS.
-------- ---------- --------
|Serving| Tunnel=3 | Anchor | Tunnel=1 | LNS |
| LAC1 | ----------| LAC |-----------| |
-------- callid=1 --------- callid=3 --------
/
/
/ Tunnel=2, callid=5
-------------
| New |
|Serving LAC2 |
-------------
Chuah expires June 1st, 1999 [Page 5]
Internet Draft Mobile PPP Nov 18th, 1999
Client S-LAC2 A-LAC LAC1 LNS
Link Layer
Msg1 SCCRQ
---------> ---------->
SCCRP (Mobile AVP)
<---------
SCCCN
------------>
ICRQ (with User AVP)
-------------> CDN
------------>
ICRP
<-------------
ICCN Auth_Req (Optional)
-------------> ------------------------>
ACK
<----------
Link Layer
Msg2
<---------
2-hop to 2-hop Handover Scenario
Fig 4 Independent Tunnel Approach
In Fig 4, we show a 2-hop to 2-hop handover scenario. When the Anchor
LAC receives the ICRQ with an attached User AVP, and finds an entry in
the mapping table, it concludes that this is a 2-hop to 2-hop handover
scenario. Therefore, the Anchor LAC sends a CDN message to the old LAC,
and updates the mapping table with the new
tunnel and call identities carried within the ICRQ message. Again,
if a user-level re-authentication is desired, the Anchor LAC can
send an Authentication Request message to the LNS to trigger such
a reaction.
The advantages of ITA are:
(a) the handover latency is reduced due to a shorter hop distance
between the Serving LAC and the Anchor LAC. The hop between the
Anchor LAC and the LNS remains unchanged.
(b) Roaming service can be more flexible. As long as there is an
agreement between the home WSP and the corporate network, and between
the home WSP and other WSPs, the subscribers can roam to more
places without having to terminate the PPP session.
The disadvantages of ITA are
(a) more complex than the Simple AVP approach
(b) the Anchor LAC needs to maintain 2N flow-controlled data sessions
for N PPP calls.
2.3 Concatenated Tunnel Approach (CTA)
In the Concatenated Tunnel Approach, there is only one L2TP
session per call but this L2TP session spans two hops: one between
the Serving LAC and the Anchor LAC; one between the Anchor LAC and LNS.
This approach requires more software enhancements to the Anchor
LAC. However, the advantage is that it has end-to-end flow control
and less CPU processing than the ITA.
Chuah expires June 1st, 1999 [Page 6]
Internet Draft Mobile PPP Nov 18th, 1999
---------- --------
| Anchor | Tunnel=1 | LNS |
| LAC |-----------| |
--------- callid=3 --------
|
|
| Tunnel=3, callid=1
-------------
|Serving LAC |
-------------
Client S-LAC A-LAC LNS
Link Layer
Msg1 SCCRQ
---------> ---------->
SCCRP (with Mobile AVP)
<---------
SCCCN
------------>
ICRQ (with User AVP)
------------->
ICRP (with Seq No, ACCM, Proxy Auth AVPs)
<-------------
ICCN Auth_Req (Optional)
-------------> ------->
ACK
<----------
Link Layer
Msg2
<---------
One hop to 2-hop Handover Scenario
Fig 5 Independent Tunnel Approach
The main differences between CTA and ITA are:
(i) For CTA, there is only one flow control procedure for the 2 hop.
Thus, he Anchor LAC needs to send a Sequence Number AVP (which contains
information on the latest Nr,Ns used before the handover) to
the Serving LAC so that the Serving LAC knows what sequence numbers
to start with.
(ii) For CTA, the Anchor LAC merely observes and updates the latest
(Nr, Ns) information within the data packets traversing in either
direction. It does not have to perform flow control actions on
two data sessions as in the ITA.
The advantages of CTA are:
(a) we have an end/end flow control for the PPP call
(b) the handover latency is reduced because of a shorter path between
the Serving LAC and the Anchor LAC.
(c) Roaming service can be more flexible. As long as there is an
agreement between the home WSP and the corporate
network, and between the home WSP and other WSPs, the subscribers
can roam to more places without service interruptions.
(d) it requires less CPU processing than ITA.
The disadvantages of CTA are:
(a) more complex than the Simple AVP and ITA approaches.
Chuah expires June 1st, 1999 [Page 7]
Internet Draft Mobile PPP Nov 18th, 1999
3 Service Model Issues
3.1 Authentication
As in [1], the authentication of the user occurs in four phases; the
first at the visiting WSP, the second at the Home WSP, and the third
and optionally the fourth at the LNS.
3.2 Accounting
It is a requirement that the Serving LAC, the Anchor LAC and the
LNS be capable of providing accounting data and hence all three
parties may count packets, octets and connection start and stop
times.
Accounting statistics collected by the Serving LAC and the Anchor
LAC are sent to their AAA Servers. The accounting Server
in the Foreign Network may forward accounting statistics
to the Home Accounting Server periodically (weekly, monthly).
4.0 Control Message Processing
For the 3-hop scenario, we assume that any party, namely the Serving
LAC, the Anchor LAC or the LNS can terminate the session by sending a Call
Disconnect Notify. If the Anchor LAC desires to terminate the session,
then the Anchor LAC has to send a Call Disconnect Notify message to
both the Serving LAC and the LNS.
Note that in the three hop scenario, the Hello messages for the
control connections between the Serving/Anchor LACs and between
the Anchor LAC and LNS are done independently of one another for both
the Independent and Concatenated Tunnel approaches. The Anchor LAC is
expected to relay all the Set-Link-Info, and Wan-Error-Notify messages.
4.1 Newly Defined Control Message and AVPs.
To support the tunnel extension and call transfer features, we define
one optional control message, namely the Auth_Request message. This
message allows the LAC to inform the LNS to trigger a PPP level
re-authentication with the PPP client during handover.
In addition, we define four new AVPs: (i) Mobile AVP, (ii) User AVP,
(iii) Sequence Number AVP, (iv) A-LAC Window AVP. The Sequence No,
A-LAC Window are used only in the CTA. We refer the readers to
Appendix 1 for more information on when these 3 AVPs are used in the CTA.
4.1.1 Authentication Request (Auth_REQ)
Authentication Request message is sent from a LAC to an LNS to trigger
the LNS from initiating a PPP reauthentication with an existing
user.
Message Format for Authentication Request
++++++++++++++++++++++++++++++++++++++
|L2TP control message header |
++++++++++++++++++++++++++++++++++++++
|Authentication Request |
++++++++++++++++++++++++++++++++++++++
Chuah expires June 1st, 1999 [Page 8]
Internet Draft Mobile PPP Nov 18th, 1999
4.1.2 Newly Defined AVPs
The new AVP is encoded as Vendor ID 1751 which reflects Lucent
Systems, the initial developer of this specification, and it
should be changed to 0 and an official Attribute value chosen if
this specification advances on a standards track).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Overall Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [until Overall Length is reached]... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first six bits are a bit mask, describing the general
attributes of the AVP.
The three newly defined AVPs are:
Attr M Len Attribute Name
40 1 8 Mobile AVP
41 1 16+ User AVP
42 1 10 Sequence Number AVP
43 1 8 Receive Window Size AVP allowed by the Anchor LAC
The existing Receive Window Size AVP in [1] with Atribute vallue 10
is used to communicate the receive window size allowed by the LNS.
4.1.2.1 Mobile AVP
This AVP is used by the LNS/A-LAC to inform a LAC that the LNS/A-LAC
supports the mobility feature.
Message Format for Mobile AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|0| Length | Lucent-Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 40 | Support Mobility |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.2.2 User's AVP
This AVP is used to provide user's name and user's credentials.
The user's credentials may include information like user's
identity (IMSI), phone number. This AVP may be a hidden AVP
(according to Section 5.7 in the L2TP draft [1]).
Message Format for User's AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|0| Length | Lucent-Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 41 | User-Service |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCII Representation of 15 digit No |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Phone Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
User's AVP
- contains information about the user's name and user's
credentials e.g. multihop virtual dial up service, user's
identity (MIN), service provider's phone number, user level
authentication information, etc
Chuah expires June 1st, 1999 [Page 9]
Internet Draft Mobile PPP Nov 18th, 1999
4.1.2.3 Sequence Number AVP
This AVP is used to convey (Nr, Ns) information to the new
Serving LAC. This AVP is only used in the Concatenated Tunnel approach
and is attached to the ICRP message.
Message Format for Sequence Number AVP
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0|0| Length | Lucent-Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 42 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nr | Ns |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nr - next received sequence number to be expected.
Ns - next sending sequence number.
4.1.2.3 A-LAC Window's AVP
This AVP is used by the Anchor LAC to inform the new Serving LAC of
the A-LAC's payload window size. The original Receive Window AVP is
used to convey LNS's window size. The format is exactly the same
as the Receive Window AVP stated in [1]. This AVP is only required
for the Concatenated Tunnel approach and is attached to the
ICRP message.
5. Security Issues
In our proposal, the Serving and Anchor LACs may belong to the same
WSP or they may belong to different WSPs. For the case where they
belong to the same WSP, we do not introduce any new security threats.
For the case where they belong to different WSPs, we assume that
if a corporate net trusts a particular WSP,say WSP1, and WSP1 trusts
another WSP, WSP2, then the corporate network trusts WSP2.
IP security can be supported between Serving LAC and LNS for
the triplet case using extended ideas described in the draft
"Securing L2TP using IPSEC" [2].
6. Acknowledgements
The author wishes to thank George Gross, Jim Kallimani and Margaret
Yang for very useful comments.
7. Contacts
M. C. Chuah
Lucent Technologies
101, Crawfords Corner Road,
Holmdel, NJ 07733
chuah@lucent.com
(732)-949-7206
Don Grosser
IBM Corporation
3039 Cornwallis Road,
Research Triangle Park, NC 27709
grosser@us.ibm.com
(919)-254-2160
G. Rai
1101 Warrenville Road,
Naperville, IL
grai@lucent.com
(630)-979-8131
Jacob Teplitsky
RABU
Lucent Technologies
4464 Willow Rd,
Pleasanton, CA 94588
jacobt@livingston.com
(925) 737-2189
Chuah expires June 1st, 1999 [Page 10]
Internet Draft Mobile PPP Nov 18th, 1998
8. References
[1] A. Valencia, etal, Layer Two Tunneling Protocol, Internet draft,
draft-ietf-pppext-l2tp-12.txt, October, 1998
[2] B. Patel, B. Aboba Security L2TP using IPSEC, Internet draft,
draft-ietf-pppext-l2tp-security-01.txt, March 1998
Appendix 1 Using CTA in a Handover Scenario
Assume that the subscriber has a PPP call which spans two
hops between the S-LAC1, A-LAC and the LNS. Then, the subscriber moves
to the coverage area of a new LAC, S-LAC2.
Message Flows for this handover scenario:
S-LAC2 A-LAC S-LAC1 LNS
Link Msg1 ICRQ
--> Orig ICRQ
User's AVP
--------->
CDN
--------->
Link Msg2 ICRP
<- Orig ICRP
Seq No AVP
A-LAC Window AVP
LNS Window AVP
ACCM AVP
<----------
Link Msg3 ICCN
--> Orig ICCN Auth_Req (optional)
----------> ------------------------>
ACK
<----------
Orig ICRQ - means the ICRQ message as stated in [1]
Orig ICRP - means the ICRP message as stated in [1]
Orig ICCN - means the ICRP message as stated in [1]
Chuah expires June 1st, 1999 [Page 11]
Internet Draft Mobile PPP Nov 18th, 1998
Appendix 2 Transfer of Sequence Number During Handover
Here, we describe how the sequence numbers are updated
during a handover if CTA is used.
A2.1 Handover from a 2-hop to a 3-hop configuration.
Old LAC LNS
Ss=13 Ss=7
Sr=6 Sr=10
The old LAC (which is now the A-LAC) will set Nr=6, Ns=13 in the
Sequence Number AVP within the ICRP message. After the handover,
New S-LAC A-LAC(Old LAC) LNS
Ss=13 Ss^S=13 Ss^L=7+ Ss=7+
Sr=6 Sr^S=6 Sr^L=10+ Sr=10+
A2.2 Handover from a 3-hop to a 2-hop configuration.
Old S-LAC A-LAC LNS
Ss=13 Ss^S=12 Ss^L=6 Ss=7
Sr=5 Sr^S=4 Sr^L=9 Sr=10
The Anchor LAC will set (Ss=Ss^S, Sr=Ss^L) and drop the
4 tuple (Ss^L, Sr^L,Ss^S,Sr^S) as shown below:
A-LAC(LAC) LNS
Ss=12 Ss=7+
Sr=6 Sr=10+
A2.3 Handover from a 3-hop to another 3-hop configuration.
New S-LAC Old S-LAC A-LAC LNS
Ss=13 Ss^S=12 Ss^L=6 Ss=7
Sr=5 Sr^S=4 Sr^L=9 Sr=10
The A-LAC sets Ns=Ss^S=12, Nr= Ss^L=6 in the Sequence Number AVP
within the ICRP message which is sent to the new S-LAC. After the
handover, we have
New S-LAC A-LAC LNS
Ss=12 Ss^S=12 Ss^L=6+ Ss=7+
Sr=6 Sr^S=6 Sr^L=9+ Sr=10+
Appendix 3 Multiple LNS Scenario
For the case where a LAC may potentially communicate with more than
one LNSs, the mobile feature will still work as long as the order
at which any LAC tries a possible list of LNSs is the same.
Chuah expires June 1st, 1999 [Page 12]
Internet Draft Mobile PPP Nov 18th, 1998
| PAFTECH AB 2003-2026 | 2026-04-22 14:57:09 |