Transcript PPT Version
Candidate Access Router Discovery Protocol
<draft-ietf-seamoby-card-protocol-01.txt>
Overview of CARD Protocol Design
And Pending Issues
20th March 2003
CARD Designteam
A. Singh, D. Funato, H. Chaskar, M. Liebsch
Intro
•
The draft delivered from the design team, covers …
-
Description of CARD protocol functions.
Proposal on 2 operational modes to keep CARD protocol design
and its deployment flexible.
Proposes server based CARD protocol for network assisted
mode.
Proposes server less MN-Orchestrated CARD.
Proposes protocol messages encoding for AR-MN, AR-Server
and AR-AR interfaces.
Include security consideration discussion.
WG Comments and Issues
•
Support of AP authorization at AR (Issue-1)
- AP authorization is not supported in the current draft.
- Does this belong to the scope of the CARD protocol?
WG Comments Issues
• Characteristics of server based approach (Issue-2)
- Server based approach is able to provide seamless handoff even if
the CAR information is not available in the current AR cache.
- The server provides in built authorization function by using scopeid.
- It introduces additional single point of failure in an access network,
but this can be eliminated if CARD server function can be
integrated with existing server e.g., AAA server.
- Scope-id can be used to minimize or avoid the cache
contamination issues.
- Single server is easier to configure and manage compared to
multiple AR(s).
WG Comments and Issues
• Characteristics of handover based approach (Issue-2)
- No server required.
- The seamless handoff not possible until AR cache is
populated.
- The AR cache is only updated when MN performs active
L3 handoff.
- Additional protocol complexity for validating information
provided by MN.
•Denial of Service Attack (Issue-3)
- Possible to minimize by rate limiting the number of
AR-server requests as well as MN-AR requests.
WG Comments and Issues
Cache Contamination (Issue-4)
A proposal for solution using scope id
Server
AR(y)
AR(x)
Scope 1
Scope-1 = {AR(y), AR(x)}
Scope-2 = {AR(x), AR(z)}
AR(z)
Scope 2
Scope 1
Scope 2
WG Comments and Issues
• Piggybacking CARD options on FMIPv6
messages and use of “P” bit (Issue-5)
- DT draft optionally allows the piggybacking of MN-AR
CARD options on FMIP6 messages. To get the benefit of
the piggybacking, the FMIPv6 implementation would
need to process the CARD options.
- Do we need to have some text to clarify this in the
FMIPv6 draft?
- Do we need to restrict piggybacking to FMIPv6, or
should it be supported also with Router
Solicitation/Advertisement ?
- The “P” bit is used to discover the piggybacking
capability of CARD communication peers.
WG Comments and Issues
• What is the function of lifetime flag (Issue-6)
- The lifetime flag supports indication of dynamic or static
capabilities.
• Editorial Issues 7-10
- These issues will be addressed in the next revision of the
draft.
• IPR Issues
- There may be potential IPRs on some of CARD
optimizations?
- Do we need to keep the base draft IPR free or it is fine
have IPR on the draft?
Backup Slides
MN-Orchestrated CARD Timing Diagram
MN
Current AR
Existing IP Connectivity
L2-SCAN (1)
Establish IP Connectivity (2)
MN-AR CARD Request Option (3)
MN-AR CARD Reply Option (4)
Establish IP Connectivity (2)
MN-AR CARD Request Option (3)
MN-AR CARD Reply Option (4)
CAR1
CAR2
Network Assisted CARD Timing Diagram
Current AR
MN
CAR
CARD Server
Registrationn Request
L2-SCAN (1)
Registrationn Reply
MN-AR CARD Request Option ( 2)
AR-Server CARD Request (3)
After cache timeout
Server-AR CARD Request (4)
AR-AR CARD Request (5)
AR-AR CARD Reply (6)
MN-AR CARD Reply Option (7)
WG Comments and Issues
• Cache Contamination (Issue-4)
- To avoid the problem of cache contamination, ARs of a given domain need to be
grouped in a set of scopes in such a way that each scope would only consist up of
ARs that are neighbors (e.g., scope-1 will contain AR(a) and AR(b) only if AR(a)
and AR(b) are neighbors).
- The boarder AR would belong to more than one scopes. For example, AR(X)
would belong to two scopes if AR(X) has neighborhood relation with AR(Y) and
AR(Z) , but AR(Y) and AR(Z) are not neighbors.
- The server would resolve the L2 address of an AP to CAR IP address only if
following two conditions are met:
AP is attached to the CAR.
Both requesting AR and the CAR are the members of the same pre-configured scope.
- The above approach would ensure that any attempt to resolve an invalid AP ID by
an AR that does not belong to its neighboring AR will be rejected by the CARD
server.