CARD Review from Vijay
"James Kempf" <[email protected]>
| Newsgroups | gmane.ietf.seamoby |
|---|---|
| Message-ID | <00ac01c345df$9c6082a0$876015ac@dclkempt40> |
Review of CARD from Vijay Deverapali is attached. Vijay is on the Seamoby
Review Board.
jak
card_review.txt
(text/plain, 32 KB)
> 3.1 Reverse Address Translation
>
> If a MN can listen to L2 IDs of new APs prior to making decision
> about IP-level handover to CARs, a mechanism is needed for reverse
> address translation. This function of the CARD protocol enables the
> MN to map the received L2 ID of an AP to the IP address of the
> associated CAR that connects to the AP. To get the CAR's IP address,
> the MN sends the L2 ID of the AP to the current AR and the current
> AR provides the associated CAR's IP address to the MN.
how does this fit in with the ProxyRtrSolict and ProxyRtrAdvert
in FMIPv6? FMIPv6 already does Reverse Address Translation through
these two messages.
> In cases where the MN can acquire IP connectivity with CARs prior to
> making handover decisions, this functionality is trivially realized,
> since the MN can request CARs individually for reverse address
> translation.
in this case, is Router Solicitation and Router Advertisement
used for reverse address transaltion? what is need for CARD
messages here?
> 3.2 Discovery of CAR Capabilities
>
> Information about capabilities of CARs can assist the MN in making
> optimized handover decisions. This capability information serves as
> input to the target AR selection algorithm. Some of the capability
> parameters of CARs can be static, while some others can change with
> time.
s/while some others/while others/
> Definition of capabilities is out of scope of the CARD protocol
> design. Encoding rules for capabilities and the format of a
> capability container for capability transport are specified in
> section 5.
s/the CARD protocol design/this document/
> There are two approaches for MNs to acquire address and capability
> information of CARs. One is that the MN sends an explicit request to
> its current AR and the current AR provides address and capability
> information to the MN. The other is that the current AR either
> periodically transmits address and capability information of CARs to
> the MNs over download channels, or link-layer mechanisms trigger
> unsolicited transmission of CARs' address and capability
> information.
what is this L2 trigger which makes the AR send out unsolicited
information. the way I see it, unsolicited information is
typically sent using a timer or when there is a significant
change in the capability information.
> The CARD protocol is used to allow MNs resolving the L2 ID of one or
> more APs, which are candidates the MN may initiate a handover to, to
> the IP address of the associated CARs, as well as to discover these
> CARs' capabilities. Furthermore, the protocol allows populating
> ARs' CAR tables (section 4.1) with the capabilities of CARs.
>
> For this, the CARD protocol makes use of a CARD Request and CARD
> Reply protocol message handshake between a MN and its current AR,
> and between a MN's current AR and individual CARs respectively. CARD
> Request and CARD Reply messages are used on the interface between a
> MN and its current AR to allow MNs retrieving CARs' address and
> capability parameter specific information from the network. To allow
> ARs populating and maintaining their local CAR table with capability
> parameter information of CARs, a CARD Request and CARD Reply
> protocol message handshake is also used on the interface between a
> MN's current AR and CARs to allow updating ARs' CAR table entries
> with CARs' capability information.
reword the first two paragraphs. too verbose and repetitive.
The CARD protocol is used to allow MNs resolving the L2 ID of one or
more APs, which are candidates the MN may initiate a handover to, to
the IP address of the associated CARs, as well as to discover these
CARs' capabilities. Furthermore, the protocol allows each AR to
maintain the capability information of other CARs. For this, the
CARD protocol makes use of a CARD Request and CARD Reply protocol
message, defined in Section 5.1.2.
> An access point's L2 ID, a CAR's IP address and associated
> capability information is carried as CARD protocol message parameter
> with a CARD Request or a CARD Reply message respectively.
took a long time to figure out what the sentence says. I guess
you wanted to say a CARD Request and CARD Reply contain AP's
L2 ID and the IP address of a CAR respectively. Optionally
these messages can also contain capability information.
> The CARD protocol enables the MN's current AR to exchange
> capabilities with CARs and to subsequently convey appropriate
> capabilities to the connected MNs.
this sentence repeats what was said earlier. delete.
> The unsolicited CARD Reply SHALL be broadcast from ARs to all the
> connected MNs.
for IPv6, is all-nodes multicast address used?
> The CARD protocol also enables a MN to optionally indicate its
> preferences on capabilities of interest to its current AR, which
> allows the MN's current AR performing optional capability pre-
> filtering for optimization purposes. Appending the optional
> Preferences message parameter for a CARD Request message, which is
> sent to the MN's current AR, the MN can indicate a list of
> capability attributes, which are of interest to the MN, to its
> current AR. The AR now returns only these capabilities of interest
> to the requesting MN. The format of this optional Preferences
> message parameter is described in section 5.1.3.2.
reword
The CARD protocol also enables a MN to indicate its preferences
on capabilities of interest to its current AR, by including the
Preferences message parameter in the CARD Request message. The
current AR MAY use this information to filter the list of CARs
and include only those CARS which satisfy the MR's preferences.
The format for the Preferences message parameter is described
in section 5.1.3.2.
> Optionally, the MN can provide its current AR with a list of
> capability attribute-value pairs, indicating not only the capability
> parameters (attributes) as required for capability pre-filtering,
> but also a specific value for a particular capability. This allows
> the MN's current AR performing CAR pre-filtering and to send only
> address and capability information of CARs, whose capability values
> meet the requirements of the MN, back to the requesting MN. The
> format of this optional Requirements message parameter is described
> in section 5.1.3.3.
I dont see a need to have both Preferences and Requirements
message parameter. especially when both are optional messages.
I recommend having only one.
> As an example, using the optional Preferences message parameter, a
> MN may indicate to its current AR that it is interested only in
> IEEE802.11 interface specific capability parameters, since this is
> the only interface the MN has implemented. Hence, the MN's current
> AR sends back only CARs' IEEE802.11 specific capabilities.
> Similarly, using the optional Requirements message parameter, a MN
> MAY indicate to its current AR that it is only interested in CARs
> that can satisfy a given QoS constraint. Here, a MN sends the
> respective QoS attribute with the QoS constraint value to its
> current AR using the optional Requirements message parameter. The
> QoS constraint is denoted as an attribute-value pair and
> encapsulated with the Requirements message parameter, which is
> appended to the MN-originated CARD Request message. Based on the
> received optional list of attributes in the Preferences parameter or
> a list of attribute-value pairs in the Requirements message
> parameter, the MN's current AR MAY use these parameters for deciding
> the content of the solicited CARD Reply message, which is to be sent
> back to the MN. Alternatively, in case no optimization with regard
> to capability or CAR pre-filtering is performed by the MN's current
> AR, the current AR MAY choose to silently ignore the optional
> Requirements and Preferences message parameter as received in the
> CARD Request message.
both could be done using just the Requirements message parameter.
> ID to the IP address of the associated CAR or, in case the MN has
> not attached one or more L2 ID message parameters,
s/one or more/any/
> it just reads out
> all CARs' IP address information using the reverse address
> translation information (L2 ID to IP address mapping) from its local
> CAR table. In case one or more capability entries have expired in
> the current AR's CAR table, the current AR then directly contacts
> the CAR and performs capability discovery with it by performing an
> AR-AR CARD Request (3) and AR-AR CARD Reply (4) protocol message
> handshake to retrieve individual CARs' capability information. The
> current AR then updates capability entries in its local CAR table
> and passes on the IP address of the CAR(s) and associated
> capabilities to the MN using the MN-AR CARD Reply message (5).
lets say, the MN is interested only reverse address translation
and not in capability information. how does the MN indicate this
to the access router? I think supporting this is essential.
> Since the MN-AR CARD Request is sent when a MN discovers new AP(s)
> during link layer scanning, sometimes a MN might send frequent MN-AR
> CARD Requests, thereby overwhelming its current AR with CARD Request
> signaling messages. To counteract this problem, the AR SHOULD set
> the R-flag (rate limiting) of a subsequent CARD Reply message for
> flow-control purposes (section 5.1.2.2), thereby requesting the MN
> to reduce the generation rate of MN-AR CARD Requests. Upon receipt
> of the MN-AR CARD Reply with the R-flag set, the requesting MN MUST
> reduce the rate of generation of MN-AR CARD Requests. The exact
> implementation of a rate-limiting algorithm should be decided by the
> implementers.
whats the need for an R flag? its not required, IMO.
I recommend the following
The MN MUST send only one CARD Request per CARD_RETRANSMISSION_INTERVAL
and not more than CARD_MAX_RETRIES.
add to the constants section
CARD_RETRANSMISSION_INTERVAL 1 second
CARD_MAX_RETRIES 3
if the MN sends requests more frequently, the AR just drops them.
the above is a well known rate-limiting technique used by a
large number of protocols. we should stick to this.
> ARs SHALL also keep and maintain individual CARs' capabilities in
> the local CAR table, taking the associated capability lifetime into
> account. If the lifetime of an individual capability entry has
> expired, the respective capability is to be discovered and to be
> updated when requested from a connected MN. The ARs' CAR table may
> be implemented differently by the different implementations, hence
> additional details are not provided here.
why is this a MUST? SHALL means MUST. SHOULD is enough. I
might be designing a system where all Access Router have
the same capabilities and all I need is an L2 ID to IP
address mapping.
> To initiate CARD, a MN sends a CARD Request to its current AR,
> requesting it to resolve the L2 ID of nearby access points to the IP
> address of associated CARs, and also to obtain capability parameters
> associated with these CARs. In case the requesting MN want its
> current AR to resolve specific L2 IDs, the MN-AR CARD Request SHOULD
> contain the CARD protocol specific L2 ID message parameters,
delete the following. redundant.
> carrying the L2 ID of respective access points, for which reverse
> address translation to associated CARs' IP address as well as CARs'
> capability information is being requested.
delete the following. already mentioned earlier.
> For example, using the Preferences message parameter, a
> MN may indicate that it is only interested in these CAR(s)
> supporting a specific air interface technology. Similarly, using the
> Requirements message parameter, a MN can indicate the list of
> capability attributes and associated capabilities' values to its
> current AR. The Requirements message parameter may be used to
> indicate the cut off values of the capabilities for the desired
> CAR(s).
also delete the following sentence. we are describing the MN's
operation in this section.
> The MN's current AR MAY use the Preferences and Requirement
> message parameter to decide about a sub-set of the CAR(s) that can
> satisfy the MN's need.
>
> 4.2.2 Current Access Router Operation
>
> Upon receipt of the requesting MN's MN-AR CARD-Request, containing
s/the requesting MN's/a/
> one or multiple L2 ID message parameters, the connected AR SHALL
> resolve the requested APs' L2 ID to the IP address of the associated
> CAR(s). In case no L2 ID parameter has been sent with the MN-AR CARD
> Request message, the MN's current AR retrieves all CARs' IP address
> and capability information from its local CAR table. Optionally,
> when allowed by local policies and supported by respective ARs, the
> AR MAY retrieve a subset of capabilities or CARs, satisfying the
> optionally appended Preferences and Requirement message parameter,
> from its local CAR table. CARs' address information along with
> associated capabilities are then delivered to the MN using the MN-AR
> CARD Reply message,
delete the following.
> having the Address message parameters and
> appropriate Capability Container parameters appended.
> The CARs' IP
> address as well as the capabilities SHALL be encoded according to
> the format for CARD protocol message parameters as defined in
> section 5.1.3 of this document. The capabilities are encoded as
> attribute-value pairs, which are to be encapsulated in a Capability
> Container message parameter according to the format defined in
> section 5.1.3.4. The responding current AR shall copy the sequence
> number received in the MN-AR CARD Request to the MN-AR CARD Reply.
there was no mention of the sequence number in Section 4.2.1.
> Request. The MN's current AR SHALL use the IPsec ESP for
> authenticating the AR-AR CARD Request. The IPsec ESP MAY be also
> used for encrypting the capability information.
this is not how you specify IPsec requirements. replace the above
sentence with
The MN's current AR SHOULD use IPsec for authenticating the
AR-AR CARD Request. If the capability information needs to be
encrypted ESP MUST be used.
question, a broadcast unsolicited CARD Reply message cannot
be protected by IPsec. how is the SA created?
>
> Upon receipt of the AR-AR CARD Reply, which has been sent by the CAR
> in response to the previously sent request, the MN's current AR
> SHALL extract the capability information from the payload of the
> received message and buffer the received capabilities in its local
> CAR table. The lifetime of individual capabilities is to be set
> according to the lifetime indicated for each capability received.
> The value of the table entries' timeout shall depend upon the nature
> of individual capabilities. Then the AR MUST send the MN-AR CARD
> Reply to the Mobile Node.
s/Then the AR MUST send/Then the AR sends/
> 4.3.2 Candidate Access Router Operation
>
> Upon receipt of a AR-AR CARD Request, a CAR shall extract the
> capabilities of the MN's current AR from the payload of the received
> message. The CAR SHALL buffer the received capabilities in its CAR
> table and set the timer for individual capabilities appropriately.
> The value of the table entries' timeout depends upon the nature of
> capabilities received. The CAR then MUST respond with the AR-AR CARD
s/CAR then MUST respond/CAR then responds/
> Reply message. The CAR MUST include the same sequence number
> received in AR-AR CARD Request message to the AR-AR CARD Reply
> message. The AR-AR CARD Reply shall include the CAR's capabilities
> as list of attribute-value pairs in the Capability Container message
> parameter. The CAR SHALL use IPsec ESP for authentication or
> optionally encryption of the AR-AR CARD Reply message.
the same as before. replace last sentence with
The CAR SHOULD use IPsec for authenticating the AR-AR CARD Reply
message. If the capability information needs to be encrypted
ESP MUST be used.
>
> 4.4 CARD Signaling Failure Recovery
>
> For a variety of reasons, the packets carrying CARD protocol
> signaling may be dropped. In this section we consider mechanisms for
> recovery from the CARD signaling failures. Broadly the CARD
> signaling failures can be categorized in MN-AR signaling failures
> and AR-AR signaling failures.
>
>
> 4.4.1 MN-AR Signaling Failure
>
> It is likely that either a CARD Request or CARD Reply may be dropped
> due to poor radio link conditions. A MN SHALL detect the loss of a
> MN-AR CARD Request or MN-AR CARD Reply Message using a timeout
> mechanism (MN_AR_CARD_TIMEOUT). The AR SHALL start a timer
> (MN_AR_CARD_TIMER) after sending a MN-AR CARD Request message with
> the given sequence number. The MN SHALL stop the timer as soon as
> the reply to the MN-AR CARD Request is received by it. Upon
> expiration of the MN_AR_CARD_TIMER, the MN SHALL declare the
> outstanding message as lost, resends the same message and restart
> the MN_AR_CARD_TIMER. The MN shall retry the MN-AR CARD Request for
> a pre-configured number of times (MN_AR_CARD_RETRIES) before
> declaring the protocol message exchange aborted. The MN SHALL
> silently discard any duplicate MN-AR CARD Reply messages received
> from its current AR.
>
>
> 4.4.2 AR-AR Signaling Failure
>
> It is likely that a AR-AR CARD Request or AR-AR CARD Reply may be
> dropped due to congestion at the intermediate routers or poor link
> conditions. The MN's current AR SHALL detect the loss of an AR-AR
> CARD Request or an AR-AR CARD Reply message using a timeout
> mechanism (AR_AR_CARD_TIMEOUT). The current AR SHALL start a timer
> (AR_AR_CARD_TIMER) after sending the AR-AR CARD Request with the
> given sequence number. The current AR SHALL stop the timer as soon
> as the reply to the AR-AR CARD Request is received by it. Upon
> expiration of the AR_AR_CARD_TIMER, the MN's current AR SHALL
> declare the outstanding AR-AR CARD Request as lost and then resends
> the same message to the CAR. The current AR SHALL retry the AR-AR
> CARD Request message for a pre-configured number of times
> (AR_AR_CARD_RETRIES) before declaring the protocol message exchange
> as aborted. The current AR SHALL silently discard any duplicate AR-
> AR CARD Reply received from the CAR.
>
replace entire section 4.4 with the following
4.4 Retransmission of CARD messages
In the event of a CARD Request or a Reply message getting dropped,
the MN and the AR SHOULD retransmit the Request message. A CARD
Request message is retransmitted if there is not reply for
CARD_REQUEST_TIMEOUT seconds. CARD Request messages MUST not be
sent more than MAX_CARD_RETRIES times.
since both MN and AR follow the same procedure, I dont see a point
in describing the same twice.
> 4.6 CARD Protocol Security
>
> The MN-AR and AR-AR messages SHALL be protected using IPsec ESP
s/SHALL be protected using IPsec ESP/MUST be protected using IPsec.
> IP Fields:
>
> Source Address:
> An IP address assigned to the sending
> interface.
>
> Destination Address:
> An IP address assigned to the receiving
> interface.
are link local addresses okay? if you want IPsec protection,
shouldnt global addresses be used? link local addresses on
both the old link and the new link would be same. OTOH,
if unsolicited CARD Reply messages are sent
>
> Hop Limit: 255
>
> Encapsulating Security Payload (ESP) Header:
> The sender SHOULD include the Encapsulating
> Security Payload (ESP) Header, based on the
> previously established Security Association
> between the sender and the receiver.
there is no need to mention ESP header. you are describing
CARD Header Format here.
> Valid Options:
>
> CARD Request: The CARD Request allows entities to request CARD
> specific information from ARs. To process the
> CARD Request message on the receiver side,
> further sub-options must be carried, serving as
> input to the reverse address translation
> function and/or capability discovery function.
would it be better if the description goes to section 5.1.2.1.
>
> CARD Reply: The CARD Reply carries parameters, previously
> requested with a CARD Request, back to the
> sender of the CARD Request. In case of
> unsolicited address information and capabilities
> are to be sent to a node, the sender uses the
> CARD Reply without getting an explicit CARD
> Request before. Further sub-options will be
> associated with the CARD Reply message.
the same as above. the description should be in 5.1.2.2.
> 5.1.2.1 CARD Request Option
>
> 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| Reserved |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Sequence Number |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Sub-Options
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
>
> Fields:
>
> Type: T.B.A
>
> Length: The length of the option in units of octets, including
> the type and length fields as well as sub-options.
>
> Flags: P-flag: Indicates CARD protocol message piggybacking
> capability of the CARD Request message sender.
> A description for proper use of this flag can
> be found in section 4.5 of this document.
>
> Reserved bits MUST be initialized with 0.
>
> Sequence Number:
> Allows correlating requests with replies.
>
>
> Valid Sub-Options:
>
> - L2 ID sub-option
> - Preferences sub-option
> - Requirements sub-option
mention alignment requirement of 4n.
> 5.1.2.2 CARD Reply Option
>
> 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|U|R| Reserved |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Sequence Number |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Sub-Options
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
>
>
> Fields:
>
> Type: T.B.A
>
> Length: The length of the option in units of octets, including
> the type and length fields as well as sub-options.
>
> Flags: P-flag: Indicates CARD protocol message piggybacking
> capability of the CARD Request message sender.
> A description for proper use of this flag can
> be found in section 4.5 of this document.
>
> U-flag: Indicates an unsolicited CARD Reply.
> A description for proper use of this flag can
> be found in section 4 of this document.
>
> R-flag: Indicates exceeding CARD Request rate
> limitation. A description for proper use of
> this flag can be found in section 4 of this
> document.
the R-flag is a bad idea.
>
> Reserved bits MUST be initialized with 0.
>
> Sequence Number:
> Allows correlating requests with replies.
>
>
> Valid Sub-Options:
>
> - L2 ID sub-option
> - Capability Container sub-option
> - Address sub-option
if unsolicited CARD reply is broadcast, the destination address
(for IPv6) becomes all-nodes multicast address. I think this
should be mentioned here. also please mention alignment
requirement of 4n.
>
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Sub-Option Type|Sub-Option Len | Context-ID |M| L2-Type |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | L2 ID . . .
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
>
>
> Sub-Option Type:
> T.B.A
>
> Sub-Option Length:
> Length of the Sub-Option (including type and length
> fields as well as L2 type indicator) in units of 8
> octets.
>
> Context-ID: Identifies associated L2 ID, IP address and
> capability information, when coming with separated
> sub-options.
what is a Context-ID? it is mentioned for the first time here. it
was not used in the protocol description earlier.
>
> M-flag: This flag indicates that the Context-ID of this
> particular L2 ID sub-option has been modified by the
> MN's current AR and set to the same value as a
> preceding L2 ID received in the same CARD Request
> message. This adjustment appears in case this L2 ID's
> associated access point is served by the same CAR as
> a preceding access point's L2 ID, hence, the same
> Capability Container and Address sub-option,
> describing a CAR's IP address and associated
> capabilities, is valid for this particular L2 ID.
I couldnt figure out what is being said here.
> L2 type: Indicates the interface type (optional)
> (Ethernet, IEEE802.11b, ...).
>
> If the L2 type indicator is not used, this field MUST
> be set to 0.
needs to alloted IANA types. this is not mentioned in the IANA
considerations. (rthis)
>
> 5.1.3.2 Preferences Sub-Option
>
> 5.1.3.3 Requirements Sub-Option
I feel these two should be combined.
>
> 5.1.3.4 Capability Container Sub-Option
>
>
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Sub-Option Type|Sub-Option Len | Context-ID |P| Reserved |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | AVPs
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
>
>
> Sub-Option Type:
> T.B.A
>
> Sub-Option Length:
> Length of the Sub-Option (including type and length
> fields as well as AVPs) in units of 8 octets.
>
> Context-ID: Identifies L2 ID, IP address and capability triples,
> coming with separate sub-options.
I still cant figure out the Context-ID.
>
> Flags: P-flag: Indicates piggybacking capability of a CAR.
> This flag allows a MN already after a CARD process to
> know about a selected new AR's piggybacking
> capability.
piggybacking capability for a sub-option? if the Capability
Container Sub-Option is always used with either the CARD
Request or CARD Reply options, why do you need piggybacking
for this sub-option?
is it for piggybacking the sub-option on any ICMP message?
for example is it for piggybacking this sub-option on the
Link-layer Address Option (section 6.5.3 of
http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-06.txt)?
> 5.1.3.5 Address Sub-Option
>
>
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |Sub-Option Type|Sub-Option Len | Context-ID | Address Type |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Address . . .
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - -
>
>
> Sub-Option Type:
> T.B.A
>
> Sub-Option Length:
> Length of the Sub-Option (including type and length
> fields) in units of octets.
>
> Context-ID: Identifies L2 ID, IP address and capability triples,
> coming with separate sub-options.
>
> Address Type: Indicates the type of the address.
>
> 0x01 IPv4
> 0x02 IPv6
if IPv6 address is present, then this sub-option requires an
alignment requirement of 8n+4.
> 5.1.4 Capability AVP encoding rule
>
>
> 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
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | AVP Code |S| Res | AVP Length |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Attribute Lifetime (present if S = 0) |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> | Data . . .
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - -
>
> Flags: S-flag (Static) 1: identifies a static attribute,
> lifetime field is not present.
> Data will follow immediately
> after the AVP Length field.
>
> 0: identifies a dynamic attribute,
> lifetime field indicates the
> attribute's lifetime.
>
> Reserved (Res) flags MUST be set to 0.
>
> Lifetime: Specifies the lifetime of the encoded capability
> in seconds. This field is only present if the encoded
> capability has a lifetime associated and the S-bit
> has not been set.
why complicate things? let the lifetime field be there always.
if the lifetime is set to infinity, then it means it is a
static attribute. if the lifetime is set to a valid value,
then it means the attribute is a dynamic attribute.
>
> 5.2 CARD Messages for the inter-Access Router Protocol Operation
>
> 5.2.1 Protocol Transport
>
> For the CARD protocol operation on the network side between a MN's
> current AR and CARs, UDP [9] is used as transport for CARD protocol
> messages. The associated UDP port for the CARD protocol operation is
> T.B.A.
why not ICMP between the Access Routers? when a router receives a
CARD Request message, it needs separate processing in both ICMP
and UDP modules.
>
> Description Type Interface
> | | / \
> | | MN-AR AR-AR
> ---------------------------------------------------------------
> L2 ID T.B.A x
> Preferences T.B.A x x
I dont remember reading any where in the text where the Preferences
sub-option is used between Access Routers? did I miss it?