Comments on draft-melia-mipshop-mstp-solution-00

First of all, I appreciate the Design Team members to work hard to
come up with the draft to meet IEEE 802.21 WG's expectation.  

My comments are given below.  As part of my IETF liaison task in
802.21 WG, I also requested two 802.21 WG members to review the draft.
Their review comments will come in a week or two.

---------------------------------------------------------------------
General comments: I like the document organization, especially
sections 3 and 5 to cover all possible deployment scenarios.  I have
no issue with combined use of DHCP and DNS for MIH PoS discovery.  I
have an issue with allowing only either TCP or UDP for L3-MSTP.  I
think that we can make TCP and UDP mandatory supported transport
protocols to ensure interoperability, but we should not exclude other
transport protocols if appropriate and available for a particular
deployment.

More specific comments are inline. Please find [YO] tags for them.

1.  Introduction

   This document proposes a solution to the issues identified in the
   problem statement document [I-D.ietf-mipshop-mis-ps] for the
   transport of IEEE 802.21 MIH protocols.

[YO] s/the transport/the layer 3 transport/.
     s/MIH protocols/MIH (Media-Independent Handover) protocol/.

   The MIH Layer 3 transport problem is divided in two main parts: the
   discovery of mobility services (MoS) and the transport of the

Re: IETF MIPSHOP MIH L3 transport - Internet draft (DHCP comments)

_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop

RE: Comments on draft-melia-mipshop-mstp-solution-00

Please see inline: 

-----Original Message-----
From: ext Yoshihiro Ohba [mailto:yohba <at> tari.toshiba.com] 
Sent: Friday, October 05, 2007 3:53 PM
To: mipshop <at> ietf.org
Subject: [Mipshop] Comments on draft-melia-mipshop-mstp-solution-00

First of all, I appreciate the Design Team members to work hard to come up
with the draft to meet IEEE 802.21 WG's expectation.  

My comments are given below.  As part of my IETF liaison task in
802.21 WG, I also requested two 802.21 WG members to review the draft.
Their review comments will come in a week or two.

---------------------------------------------------------------------
General comments: I like the document organization, especially sections 3
and 5 to cover all possible deployment scenarios.  I have no issue with
combined use of DHCP and DNS for MIH PoS discovery.  I have an issue with
allowing only either TCP or UDP for L3-MSTP.  I think that we can make TCP
and UDP mandatory supported transport protocols to ensure interoperability,
but we should not exclude other transport protocols if appropriate and
available for a particular deployment.

<gabor> I guess you meant mandatory for the server side only.

More specific comments are inline. Please find [YO] tags for them.

1.  Introduction

   This document proposes a solution to the issues identified in the
   problem statement document [I-D.ietf-mipshop-mis-ps] for the
   transport of IEEE 802.21 MIH protocols.

[YO] s/the transport/the layer 3 transport/.
     s/MIH protocols/MIH (Media-Independent Handover) protocol/.

   The MIH Layer 3 transport problem is divided in two main parts: the
   discovery of mobility services (MoS) and the transport of the
   information between MN and MoS.  

[YO] I have two comments here.  First, according to Section 5.2 of
[I-D.ietf-mipshop-mis-ps], "the discovery of mobility services (MoS)"
means "service discovery" (i.e., discovery of services provided by a certain
node).  On the other hand, it seems that this document is trying to solve
"node discovery" (i.e., discovery of nodes that support certain services).
Second, since the term MoS is not used for representing nodes, it is
incorrect to say "the transport of the information between MN and MoS".

So, the sentence should read:

"
   The MIH Layer 3 transport problem is divided in two main parts: the
   discovery of a node that supports certain mobility services (MoS) and
   the transport of the information between a MN and the discovered node.
"
<g> well, the result of the discovery is not necessarily a node, but rather
a set of (transport) addresses where services are reachable. But yes, a
reformulation is needed there.

   The discovery process is required
   for MIH function located in the MN to discover the peer MIHF (e.g.
   the IP address) of the MoS in the network (e.g. the Point of Service,
   PoS) either during attachment or during handover.  Upon successful
   discovery, the MIH peers can then exchange information in the form of
   MIH messages.

[YO] I don't think we need the wording "either during attachment or during
handover" here, because discovery can happen at any time whenever needed.
Also, I would suggest rewriting the above two sentences to:

"
   The discovery process is required for the MN to obtain the
   information needed for MIH protocol communication with a peer node.
   The information includes the transport address (e.g., the IP
   address) of the peer node and the types of MoS provided by the
   peer node.
"
Again, it is not necessarily 'a peer node', rather peer MIHFs.

   This document considers firstly standard track IETF-based solutions
   for the design and recommendations of the discovery and transport
   protocol components.

[YO] Meaning of the above sentence is not clear.  Perhaps the above sentence
could be revised to: 

"
This document provides the overall solution for discovery and transport
protocol components while parameters and formats specific to particular
discovery components are defined in separate documents [doc1],[doc2].
"

2.  Terminology

   The following terminology is being used:

   MIH  Media Independent Handover

   MIHF  Media Independent Handover Function

   MIHF USER  MIH client initiating and terminating MIH signalling

[YO] s/MIHF USER/MIH User/.

   MIHFID  Media Independent Handover Function Identifier

   MoS  As defined in the problem statement document it includes IS, CS,
      ES services defined by the IEEE 802.21 standard.

[YO] s/the problem statement document/[I-D.ietf-mipshop-mis-ps]/.

   MoSh  Mobility Services assigned in the Home Network

   MoSv  Mobility Services assigned in the Visited Network

   MoS3  Mobility Services assigned in a 3rd Party Network

[YO] I would suggest to use the terms PoSh (Point of Service in the Home
Network), PoSv (Point of Service in the Visited Network) and PoS3 (Point of
Service in a 3rd Party Network) for the above three terms.
The reason for this is that, strictly speaking in terms of
[I-D.ietf-mipshop-mis-ps], the document deals with node discovery not
service discovery as I mentioned above.  For the same reason, I also suggest
rewrite Section 3 and Section 5 using PoSh, PoSv and PoS3.

   MN Mobile Node

   NN Network Node

[YO] The term NN is unused in the document.

[YO] Please also add the following terms.

"
 PoS (Point of Service)  A network-side MIHF instance that exchanges MIH
messages with an MN-based MIHF.

 MSTP (Mobility Services Transport Protocol) "

3.  Deployment Scenarios

(snip)

   MoS can be provided independently and there is no strict relationship
   between ES, CS and IS.  However, while IS contain more a static sort
   of information, ES and CS are services of a dynamic nature and
   sometimes some relationships between them could be expected, e.g. a
   handover command could be issued upon reception of a link event.
   Hence, while in theory services can be implemented in different
   locations, it is expected that ES and CS will be collocated, whereas

[YO] s/in different locations/on different nodes/

   IS can either be collocated with ES/CS or not.  Therefore, having the

[YO] s/collocated/co-located/ in the above two lines.

   flexibility at the MSTP to discover different services in different
   locations is an important feature

[YO] s/to discover different services in different locations/to discovery
different nodes with different services/.

[YO] s/feature/feature./.

4.  Solution Overview

   As mentioned in Section 1 the solution space is being divided in
   discovery and transport.  The following assumptions have been made:

   o  The solution is aimed at supporting 802.21 MIH services, namely
      Information Services (IS), Event Services (ES), and Command
      Services (CS).

[YO] s/Information Services/Information Service/.
     s/Event Services/Event Service/.
     s/Command Services/Command Service/.

   o  If the MIHFID is available, FQDN or NAI's realm is used for
      mobility service discovery.  The recommendation to the IEEE 802.21
      WG is to restrict to only these two.

[YO] I think that this recommendation is only for MIHFID of PoS.  I think
that MN can still use other types of MIHFID.  Also, I think that this
recommendation is specific to L3-MSTP which is part of IETF work, and I
think we don't need recommend this to the 802.21 WG.

   o  The solutions are chosen to cover all possible deployment
      scenarios as described in Section 3.

   o  MIHF discovery can be performed during initial network attachment
      or thereafter.

   For the discovering the location of an MoS, the MN could either be
   pre-configured with the address of the MoS, or this address could be
   dynamically assigned through DHCP or DNS by the network.  The dynamic
   assignation methods are described in Section 5.

   The configuration of the MoS could be executed either upon network
   attachment or after successful IP configuration.  The methodology to
   be used depends on the considered deployment scenario.

   Once the MIHF peer has been discovered, MIH information can be
   exchanged between peers over UDP and TCP.  The usage of these
   protocols is described in Section 6.

[YO] Why only UDP and TCP?  Please see my comment on Section 4.1 and Section
6 as well.

<g> the options we have here are:
Mandate one transport protocol to be used by one specific service (eg TCP)
Mandate two transport protocols to be supported by the server side (UDP and
TCP) and let the client choose
Mandate the above two for server side and allow all other possible ones; in
this case we need different NAPTR application tags for each additional
transport and support transport protocol discovery. Would the added value
justify this?

4.1.  Architecture

   The following Figure 5 depicts the MSTP reference model and its
   components within a node.

    +--------------------------+
    |       MIHF USER          |
    +--------------------------+
                 ||
    +--------------------------+
    |           MIHF           |
    +--------------------------+
        ||         ||       ||
    +---------+ +------+ +-----+
    | TCP/UDP | | DHCP | | DNS |
    +---------+ +------+ +-----+

[YO] s/MIHF USER/MIH User/.

                            Figure 5: MN stack

   As it can be seen, the MIHF relies on the services provided by TCP
   and UDP for transport, as well as DHCP and DNS for peer discovery.
   In cases where peer MIHF IP address is not pre-configured, source
   MIHF needs to discover it either via DHCP or DNS or using a
   combination of both as described in Section 5.  Once peer MIHF is
   discovered, MIHF must exchange messages with its peer over either UDP
   or TCP.  Specific recommendations on choice of transport protocols
   are provided in Section 6.

[YO] I am not sure why transports other than UDP and TCP should not be
allowed in some deployment, while I think that UDP or TCP should be
mandatory supported transport in any deployment.

<g> we could add SCTP, I could see value in that. But I do not want to flood
the documents with additional service tag definitions and transports which
are anyway not used in real life deployments.

   The above reference architecture however does not provide the model
   for other services such as, fragmentation and security.  Depending
   upon the MIH services (e.g., ES, CS and IS) the message size can be
   very large.  In cases where underlying layer does not support
   fragmentation, this may be an issue.  There is no security available
   currently at the MIH protocol level.  However, security can be
   provided either at the transport or IP layer where it is necessary.
   Section 8 provides some guidelines and recommendations for security.

4.2.  MIHF Identifiers (FQDN, NAI)

   An MIHFID is an identifier required to uniquely identify the MIHF end
   points for delivering the mobility services (MoS).  Thus an MIHF
   identifier needs to be unique within a domain whereby mobility
   services are provided and invariant to interface IP addresses.  An
   MIHFID MUST be represented either in the form of an FQDN [RFC2181] or
   NAI [RFC2486].  An MIHFID can be pre-configured or discovered through
   the discovery methods as described in Section 5.

[YO] RFC 4282 the latest specification for NAI.

5.  MoS Discovery

[YO] We should use the term PoS discovery for the reason I explained above.

   The MoS discovery method depends on whether the MN wants to discover
   an MoS in the local network, home network or a remote network other
   than home network.

[YO] s/discover an MoS/discovery a PoS/
     s/local network/visited network/.
     s/remote network/third-party network/.

   In case MoS is provided locally (scenarios S1 and S2)
   [I-D.bajko-mos-dhcp-options] and [I-D.bajko-mos-dns-discovery] could
   be used to transfer MoS information from the network to the MN (via
   DHCP or DNS).  In case MoS is provided in the home while the MN is
   attached in visited (scenario S3) an interaction between the DHCP and
   AAA infrastructure is required similarly to what specified in
   [I-D.ietf-mip6-bootstrapping-integrated-dhc].  It is assumed
   therefore that MoS assignment is performed during access
   authentication and authorization.  In case MoS is provided in a
   remote network other than visited or home (scenario S4) only DNS
   based methods apply.

(snip)

5.3.  MOS Discovery in a roaming Network and Services are at Home

   To discover an MoS in the roaming network when services are provided
   by the home network MN SHOULD use the DHCP option along with network
   access authentication.  Upon network access authentication and

[YO] Why DHCP is recommended in the roaming scenario?  I think it is also
possible to use DNS query in the same way as Section 5.1.

<g> right. I made the same point but the other authors seem deaf on this.

   interaction with the NAS the AAAh verifies in the AAA profile that
   the MN is allowed to use the MoS in home.  The AAAh assigns the MoS
   in the home and sends back the information to the NAS.  MN sends a
   DHCP information request as per [RFC3315] containing Home Network
   Identifier Option indicating the need to allocate the MoS in the
   home.  The relay agent intercepts the Information request from the MN
   and it forwards to the DHCP server inserting the MIH Relay Agent
   Option containing the info received by the AAAh.  The DHCP server can
   then reply to the MN by sending the Home Network Information Option.
   The MN receives the MoS address.

(snip)

6.  MIH Transport

   Once the Mobility Services have been discovered, MIH peers MUST
   exchange information over either TCP or UDP.  While either protocol

[YO] Why only TCP or UDP?  We would need TCP or UDP for mandatory supported
transport protocols to ensure interoperability, but IMO other transport
protocols should also be allowed if they are appropriate and available for a
particular deployment.

<g> again, the support of other transports must come along with transport
discovery mechanism and service tag definitions. We can not support
arbitrary, undefined, noname transports.

thanks for comments,
- gabor

   can provide the basic transport functionality required, there are
   performance trade-offs and unique characteristics with each that need
   to be considered in the context of the MIH services for different
   network loss and congestion conditions.  Thus, the objectives of this
   section are to discuss these trade-offs for different MIH settings
   such as the MIH message size and rate, and the retransmission
   parameters.  In addition, factors such as NAT traversal are also
   discussed.  Given the reliability requirements for the MIH transport,
   it is assumed in this discussion that the MIH ACK mechanism is to be
   used in conjunction with UDP, while it is preferred to avoid using
   with TCP since TCP includes a similar functionality.

(snip)

6.2.  MIH Message rate

   The frequency of MIH messages varies according to the MIH service
   type.  It is expected that CS/ES message arrive at a rate of one in
   hundreds of milliseconds in order to capture quick changes in the
   environment and/ or process handover commands.  On the other hand, IS

[YO] Is this the rate based on CS/ES messages coming from a single source or
multiple sources?

   messages are exchanged mainly every time a new network is visited
   which may be in order of hours or days.  Therefore a burst of either

[YO] IS exchange can happen more frequently if the MN is moving at a
high-speed.  In general, we should be careful when showing actual numbers.

   short CS/ES messages or long IS message exchanges (in the case of
   multiple MIH nodes requesting information) may lead to network
   congestion.  While the built-in rate-limiting controls available in
   TCP may be well suited for dealing with these congestion conditions,
   this may result in large transmission delays that may be unacceptable
   for the timely delivery of ES/CS messages.  On the other hand, if UDP
   is used, a rate-limiting effect similar to the one obtained with TCP
   may be obtained by adequately adjusting the token bucket parameters
   defined in the MIH specifications.  Recommendations for parameter
   settings are specific to the scenario considered.

(snip)

7.  Operation Flows

   Following Figure 10 gives an example operation flow between MIHF
   peers when an MIH user requests for an IS service.  Scenario 1 is
   chosen whereby DHCP is used for MoS discovery and TCP is used for
   establishing a transport connection.  When MOS is not pre-configured,
   MIH user needs to discover the IP address of MOS to communicate with
   the remote MIHF.  Therefore MIH user requests the local MIHF via a
   discovery message as defined in IEEE 802.21.

[YO] I don't understand why the MIH user needs to request the local MIHF for
discovering the IP address of PoS.  I think that another scenario is
possible where the MIH user directly invokes DHCP and obtains the IP
address, and then communicating the obtained IP address to the local MIHF
when invoking an MIH primitive.

(snip)

8.  Security Considerations

   There are a number of security issues that need to be taken into
   account during node discovery and information exchange via a
   transport connection [I-D.ietf-mipshop-mis-ps]

   In case where DHCP is used for node discovery and authentication of
   the source and content of DHCP messages are required, it is
   recommended that network administrators should use DHCP
   authentication option described in [RFC3118].  This will also protect
   the denial of service attacks to DHCP server.[RFC3118] provides
   mechanisms for both entity authentication and message authentication.

[YO] I think that use of DHCP authentication option is a hard recommendation
considering the fact that there is few deployment of RFC 3118 as far as I
know.  I think that recommending use of link-layer security for the link
where DHCP operates is more realistic, although it does not provide a
complete solution to address all DHCP security issues.

   In case where DNS is used for discovering MoS, fake DNS requests and
   responses may cause DoS and the inability of the MN to perform a
   proper handover, respectively.  Where networks are exposed to such
   DoS, it is recommended that DNS service providers use the Domain Name
   System Security Extensions (DNSSEC) as described in [RFC4033].
   Readers may also refer to
   [I-D.ietf-dnsop-dnssec-operational-practices] to consider the aspects
   of DNSSEC Operational Practices.

   In case where reliable transport protocol such as TCP is used for
   transport connection between two MIHF peers, TLS [RFC4346] should be
   used for message confidentiality and data integrity.  In particular,
   TLS is designed for client/server applications and to prevent
   eavesdropping, tampering, or message forgery.  Readers should also
   follow the recommendations in [RFC4366] that provides generic
   extension mechanisms for the TLS protocol suitable for wireless
   environments.

   In case where unreliable transport protocol such as UDP is used for
   transport connection between two MIHF peers, DTLS [RFC4347] should be
   used for message confidentiality and data integrity.  The DTLS
   protocol is based on the Transport Layer Security (TLS) protocol and
   provides equivalent security guarantees.

   Alternatively, generic IP layer security, such as IPSec [RFC2401] may
   be used instead of a specific transport layer secuity for a specific
   transport.

[YO] Is there a specific reason for why TLS or DTLS is a should while IPsec
is a may?  If there is such a reason, it's better to describe it.  Also, why
don't use SHOULD/MAY language here?

(snip)

Best Regards,
Yoshihiro Ohba

_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop

RE: IETF MIPSHOP MIH L3 transport - Internet draft (DHCPcomments)

> *enc* field is not familiar with DHC folks

hm. Interesting. there are RFCs already using it, eg RFC3361.

> [MoS-option-code] [len] [sub-option-code] [len1] [len1 bytes]
[sub-option-code] [len2] [len2 bytes] ...

> o MoS Suboption Code 1 = domain name
> o MoS Suboption Code 2 = IPv4 address

yes, this also works.

Or, I could define two separate options, one carrying domain names, the
other IP addresses ....

- gabor 

________________________________

From: ext Daniel Park [mailto:soohongp <at> gmail.com] 
Sent: Friday, October 05, 2007 8:25 PM
To: Zuniga, Juan Carlos
Cc: STDS-802-21 <at> listserv.ieee.org; mipshop <at> ietf.org
Subject: Re: [Mipshop] IETF MIPSHOP MIH L3 transport - Internet draft
(DHCPcomments)

This is a couple of DHCP-comments (draft-bajko-mos-dhcp-options-00) as part
of MoS discovery procedure.

[1] As I pointed out at 802.21 meeting, AFAIC, *enc* field is not familiar
with DHC folks. This is my real experience from DHC discussion long time ago
regarding *draft-daniel-dhc-mihis-opt*. The option format described here is
fairly hard to adopt. Sub-options are well understood by server
implementors, so 'proper support' would not need any code changes.  In
bried, here is a proposed new format: 

[MoS-option-code] [len] [sub-option-code] [len1] [len1 bytes]
[sub-option-code] [len2] [len2 bytes] ...

o MoS Suboption Code 1 = domain name
o MoS Suboption Code 2 = IPv4 address

Equal to DHCPv6 option format (different length and format of options)

This is immediately adoptable without code changes or requiring users to
read RFCs, by what I assume would be all DHCP server
software (it at least would be trivial for ours). For multiple encodings,
*sub-option* approach would be sufficient. 

[2] In *draft-daniel-dhc-mihis-opt*, we did propose only IS use case not ES
and CS cases. It is because I didn't see any applicable cases regarding ES
and CS in conjunction with DHCP. I know this solution document is not about
IS but about all 802.21 services (ES/CS/IS), but I am curious you are
assuming DHCP server should have all ES and CS entities information ?

 
I've quickly made some of DHCP comments. Further comments on this solution
document will be forthcoming once carefully reading this document again.

Anyhow, thanks for all of your effort on this document.

Daniel Park [at] SAMSUNG Electronics.

 
On 9/26/07, Zuniga, Juan Carlos <JuanCarlos.Zuniga <at> interdigital.com> wrote: 

	Hello guys,
	
	As Gabor mentioned in his presentation last week in the 802.21
meeting,
	the MIPSHOP MIH Transport Design Team has just produced a first
draft 
	for the solution of the L3 transport of the 802.21 MIH protocol.
	
	Please take a look at the document and provide your comments on both
	IEEE 802.21 and IETF MIPSHOP lists so that we can move forward in
having
	a final solution.
	
	A URL for this Internet-Draft is:
	
http://www.ietf.org/internet-drafts/draft-melia-mipshop-mstp-solution-00 
	.txt
	
	Best regards,
	
	Jc
	
	
	_______________________________________________
	Mipshop mailing list
	Mipshop <at> ietf.org
	https://www1.ietf.org/mailman/listinfo/mipshop
	

_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop

Re: Comments on draft-melia-mipshop-mstp-solution-00

Hi Gabor,

On Mon, Oct 08, 2007 at 03:47:54PM -0500, Gabor.Bajko <at> nokia.com wrote:
(snip)

> General comments: I like the document organization, especially sections 3
> and 5 to cover all possible deployment scenarios.  I have no issue with
> combined use of DHCP and DNS for MIH PoS discovery.  I have an issue with
> allowing only either TCP or UDP for L3-MSTP.  I think that we can make TCP
> and UDP mandatory supported transport protocols to ensure interoperability,
> but we should not exclude other transport protocols if appropriate and
> available for a particular deployment.
> 
> <gabor> I guess you meant mandatory for the server side only.

Yes, that is my preference since it allows more flexibility in MN
implementations.

(snip)

> 
>    The MIH Layer 3 transport problem is divided in two main parts: the
>    discovery of mobility services (MoS) and the transport of the
>    information between MN and MoS.  
> 
> [YO] I have two comments here.  First, according to Section 5.2 of
> [I-D.ietf-mipshop-mis-ps], "the discovery of mobility services (MoS)"
> means "service discovery" (i.e., discovery of services provided by a certain
> node).  On the other hand, it seems that this document is trying to solve
> "node discovery" (i.e., discovery of nodes that support certain services).
> Second, since the term MoS is not used for representing nodes, it is
> incorrect to say "the transport of the information between MN and MoS".
> 
> So, the sentence should read:
> 
> "
>    The MIH Layer 3 transport problem is divided in two main parts: the
>    discovery of a node that supports certain mobility services (MoS) and
>    the transport of the information between a MN and the discovered node.
> "
> <g> well, the result of the discovery is not necessarily a node, but rather
> a set of (transport) addresses where services are reachable. But yes, a
> reformulation is needed there.

I think that not only transport addresses but also MIHF-ID needs to be
discovered since the MN needs to put MIHF-ID in the Destination MIHF
Identifier TLV in MIH protocol message.

(snip)

> 
>    Once the MIHF peer has been discovered, MIH information can be
>    exchanged between peers over UDP and TCP.  The usage of these
>    protocols is described in Section 6.
> 
> [YO] Why only UDP and TCP?  Please see my comment on Section 4.1 and Section
> 6 as well.
> 
> <g> the options we have here are:
> Mandate one transport protocol to be used by one specific service (eg TCP)
> Mandate two transport protocols to be supported by the server side (UDP and
> TCP) and let the client choose
> Mandate the above two for server side and allow all other possible ones; in
> this case we need different NAPTR application tags for each additional
> transport and support transport protocol discovery. Would the added value
> justify this?

I don't see a problem with assiging NAPTR service entries for each
foreseeable transport (e.g., TCP, UDP, SCTP).

(snip)

> 
> [YO] I am not sure why transports other than UDP and TCP should not be
> allowed in some deployment, while I think that UDP or TCP should be
> mandatory supported transport in any deployment.
> 
> <g> we could add SCTP, I could see value in that. But I do not want to flood
> the documents with additional service tag definitions and transports which
> are anyway not used in real life deployments.

I agree that we should at least add SCTP.  I am not sure whether we
should add other transports at this moment.

Best Regards,
Yoshihiro Ohba

[FW: Comments on draft-melia-mipshop-mstp-solution-00]

Here is feedback from David Griffith.

Yoshihiro Ohba

----- Forwarded message from David Griffith <david.griffith <at> nist.gov> -----

X-VirusChecked: Checked
X-Env-Sender: david.griffith <at> nist.gov
X-Msg-Ref: server-13.tower-76.messagelabs.com!1192041326!89829132!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.6.16.226]
X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG
From: David Griffith <david.griffith <at> nist.gov>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
To: mipshop <at> ietf.org
CC: Yoshihiro Ohba <yohba <at> tari.toshiba.com>
Subject: Comments on draft-melia-mipshop-mstp-solution-00
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: david.griffith <at> nist.gov
X-UIDL: X9M"!aY*"!EIA"!Z0B"!

Hello everyone,

I was asked to review draft-melia-mipshop-mstp-solution-00.txt.  I have 
some revisions and comments that I'd like to share with the design team 
and the working group.  Attached is a PDF file of the draft that 
includes suggested changes and wordsmithing in blue as well as 
comments/questions in light blue.  Please let me know what you think.

Regards,
David Griffith

-- 
**********************************************

David W. Griffith, Ph.D.
Advanced Network Technologies Division
National Institute of Standards and Technology
100 Bureau Drive, Stop 8920
Gaithersburg, MD 20899-8920

Phone:  (301) 975-3512
Fax:    (301) 975-6238
e-mail: david.griffith <at> nist.gov

**********************************************

----- End forwarded message -----

_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop

Information about handoff in heterogeneous networks

_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop

Re: WG last call on FMIPv6 for 3G CDMA networks

Please go ahead.

----- Original Message ----- 
From: "Vijay Devarapalli" <vijay.devarapalli <at> azairenet.com>
To: <mipshop <at> ietf.org>
Sent: Monday, October 15, 2007 1:10 PM
Subject: Re: [Mipshop] WG last call on FMIPv6 for 3G CDMA networks

> Hello,
> 
> We have received no comments on this document. In fact there was no
> one responding to the WG last call. We can't progress this document
> to the IESG without explicit support.
> 
> I am extending the WG last call to Oct 22nd. Please review the
> document. If you have no comments and support advancing this document,
> please send an email supporting advancing this document.
> 
> Vijay
> 
> Vijay Devarapalli wrote:
> > Hello folks,
> > 
> > This is to announce a working group last call for 
> > draft-ietf-mipshop-3gfh-03.txt. You can find the document at the 
> > following URL.
> > 
> > http://www.ietf.org/internet-drafts/draft-ietf-mipshop-3gfh-03.txt
> > 
> > The last call expires on October 3 2007.
> > 
> > The intended status for this document is Informational.
> > 
> > Please post any issues or comments on this document to the MIPSHOP WG 
> > mailing list. In case you have reviewed the document and found no 
> > issues, please send an email saying you support advancing this document.
> > 
> > Vijay
> > 
> > _______________________________________________
> > Mipshop mailing list
> > Mipshop <at> ietf.org
> > https://www1.ietf.org/mailman/listinfo/mipshop
> 
> 
> 
> _______________________________________________
> Mipshop mailing list
> Mipshop <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop
> 

Re: WG last call on FMIPv6 for 3G CDMA networks

Hello,

We have received no comments on this document. In fact there was no
one responding to the WG last call. We can't progress this document
to the IESG without explicit support.

I am extending the WG last call to Oct 22nd. Please review the
document. If you have no comments and support advancing this document,
please send an email supporting advancing this document.

Vijay

Vijay Devarapalli wrote:
> Hello folks,
> 
> This is to announce a working group last call for 
> draft-ietf-mipshop-3gfh-03.txt. You can find the document at the 
> following URL.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-3gfh-03.txt
> 
> The last call expires on October 3 2007.
> 
> The intended status for this document is Informational.
> 
> Please post any issues or comments on this document to the MIPSHOP WG 
> mailing list. In case you have reviewed the document and found no 
> issues, please send an email saying you support advancing this document.
> 
> Vijay
> 
> _______________________________________________
> Mipshop mailing list
> Mipshop <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop

RE: WG last call on FMIPv6 for 3G CDMA networks

Hi Vijay, Yokota-san, 

Sorry for being late to review this. Please see my comments (tagged KC>)
in the attached file.

BR,
Kuntal

> -----Original Message-----
> From: Vijay Devarapalli [mailto:vijay.devarapalli <at> azairenet.com]
> Sent: Tuesday, September 18, 2007 5:20 PM
> To: mipshop <at> ietf.org
> Subject: [Mipshop] WG last call on FMIPv6 for 3G CDMA networks
> 
> Hello folks,
> 
> This is to announce a working group last call for
> draft-ietf-mipshop-3gfh-03.txt. You can find the document at the
> following URL.
> 
> http://www.ietf.org/internet-drafts/draft-ietf-mipshop-3gfh-03.txt
> 
> The last call expires on October 3 2007.
> 
> The intended status for this document is Informational.
> 
> Please post any issues or comments on this document to the MIPSHOP WG
> mailing list. In case you have reviewed the document and found no
> issues, please send an email saying you support advancing this
document.
> 
> Vijay
> 
> _______________________________________________
> Mipshop mailing list
> Mipshop <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/mipshop

Network Working Group                                          H. Yokota
Internet-Draft                                                  KDDI Lab
Intended status: Standards Track                              G. Dommety
Expires: January 10, 2008                            Cisco Systems, Inc.
                                                            July 9, 2007


            Mobile IPv6 Fast Handovers for 3G CDMA Networks
                     draft-ietf-mipshop-3gfh-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 10, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Yokota & Dommety        Expires January 10, 2008                [Page 1]

Internet-Draft            3G CDMA Fast Handover                July 2007


Abstract

   Mobile IPv6 is designed to maintain its connectivity while moving
   from one network to another.  It is adopted in 3G CDMA networks as a
   way to maintain connectivity when the mobile node moves between
   access routers.  However, this handover procedure requires not only
   movement detection, but also the acquisition of a new care-of address
   and the sending of a binding update message to the home agent before
   the traffic begins to direct to the new location.  During this

KC> Suggested rewrite:

   However, this handover procedure requires not only movement detection 
   by the MN, but also the acquisition of a new care-of address and Mobile 
   IPv6 registration with the new care-of address before the traffic can be 
   sent or received in the target network.


   period, packets destined for the mobile node will be lost, which may
   not be acceptable for real-time application such as Voice over IP
   (VoIP) or video telephony.  

KC> s/...mobile node will be lost.../...mobile node may be lost.../

This document specifies fast handover
   methods in the 3G context in order to reduce latency and packet loss
   during handover.

KC> s/...in the 3G context.../...in the CDMA 3G networks.../


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Network reference model for Mobile IPv6 over 3G networks . . .  6
   5.  Fast handover procedures . . . . . . . . . . . . . . . . . . .  8
     5.1.  Predictive fast handover . . . . . . . . . . . . . . . . .  8
     5.2.  Reactive fast handover . . . . . . . . . . . . . . . . . . 13
     5.3.  Network-controlled fast handover . . . . . . . . . . . . . 16
   6.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 18
     6.1.  New Option for access-specific handover information  . . . 18
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23
















Yokota & Dommety        Expires January 10, 2008                [Page 2]

Internet-Draft            3G CDMA Fast Handover                July 2007


1.  Requirements notation

   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 [1].














































Yokota & Dommety        Expires January 10, 2008                [Page 3]

Internet-Draft            3G CDMA Fast Handover                July 2007


2.  Introduction

   Mobile IPv6 [2] allows mobile nodes (MNs) to maintain persistent IPv6
   addresses while roaming around in IPv6 networks and it is adopted in
   3G CDMA networks for handing off between different access provider
   networks [4].  

KC> suggested rewrite:

   Mobile IPv6 [2] allows mobile nodes (MNs) to maintain persistent IP
   connectivity while the MN moves around in the IPv6 network. It is adopted in
   3G CDMA networks for handling host based mobility management [6].

KC> Reference [4] is not the appropriate reference here. Reference [6] should be
used instead.


During handover, however, the mobile node (MN) needs
   to switch the radio networks, to obtain a new Care-of Address (CoA)

KC> s/radio networks/radio link/

   and to re-register with the home agent (HA), which causes a
   communication disruption.  

KC> s/...which causes.../...which may cause..../


   This is not desirable for real-time
   applications such as VoIP and video telephony.  To reduce this
   disruption time or latency, a fast handover protocol for Mobile IPv6
   [3] is proposed.  In this proposal, there are two modes called
   "predictive" fast handover and "reactive" fast handover.  This
   document first specifies how these fast handover modes can be applied
   in the 3G context and shows that several Mobile IPv6 bootstrapping
   procedures can be omitted.  In the case where the lower layer can
   provide necessary information for handover, network-controlled fast
   handover defined in this document can also be applied.

KC> please replace "in 3G context" to "in 3G CDMA networks" in the entire document.

KC> Reference to Mobile IPv6 bootstrapping may be misleading here. There are Mobile
IPv6 bootstrapping solutions in IETF that may not have any relationship to handover.































Yokota & Dommety        Expires January 10, 2008                [Page 4]

Internet-Draft            3G CDMA Fast Handover                July 2007


3.  Terminology

   This document refers to [4] for Mobile IPv6 fast handover
   terminology.  Terms that first appear in this document are defined
   below:

KC> Is [4] the correct reference here?


   Forward Pilot Channel:
        A portion of the Forward Channel that carries the pilot.  The
        Forward Channel is a portion of the physical layer channels
        transmitted from the access network to the MN.

KC> s/...from the access network/...from the 3G CDMA access network.../


   Sector:
        A typical cell divides its coverage area into several sectors.
        In 3G CDMA systems, each sector uses a different PN (Pseudo
        Noise) code offset.

   Home Link Prefix (HLP):
        The prefix address assigned to the home link where the MN should
        send the binding update message.  This is one of the bootstrap
        parameters for the MN.

KC> This definition needs to be aligned with the definition of HNP in other
Mobile IPv6 documents. 


   Packet Data Serving Node (PDSN):
        An entity that routes MN originated or MN terminated packet data
        traffic.  A PDSN establishes, maintains and terminates link-
        layer sessions to MNs [4].  A PDSN can be the access router in
        the visited access provider network.

KC> s/...can be.../...is the.../























Yokota & Dommety        Expires January 10, 2008                [Page 5]

Internet-Draft            3G CDMA Fast Handover                July 2007


4.  Network reference model for Mobile IPv6 over 3G networks

KC> s/...3G networks.../3G CDMA networks/ . This fix should be applied to
the entire document.


   Figure 1 shows a simplified reference model of the Mobile IP enabled
   3G networks.  The home agent (HA) and AAA server (AAA) of the mobile
   node (MN) reside in the home IP network and the MN roams within or
   between the access provider network(s).  Usually, the home IP network
   is not populated by the MNs, which are instead connected only to the
   access provider networks.  Prior to the Mobile IPv6 registration, the
   MN establishes an access technology specific link-layer connection
   with the access router (AR).  When the MN moves from one AR to

KC> s/...access technology specific.../...3G CDMA access technology specific.../

 
   another, the link-layer connection is re-established and a Mobile
   IPv6 handover is performed.  Those ARs reside in either the same or
   different access provider network(s).  The figure shows the
   situation, where the MN moves from the previous access router (PAR)
   to the new access router (NAR) via the radio access network (RAN).

                                      Home IP Network
                                 +........................+
                                 . +--------+  +--------+ .
                                 . |   HA   |--|  AAA   | .
                                 . +--------+  +--------+ .
                                 +../......\..............+
                                   /        \
                             Access Provider Network(s)
                      +.............+      +.............+
                      . +---------+ .      . +---------+ .
                      . |   PAR   | .      . |   NAR   | .
                      . +---------+ .      . +---------+ .
                      .      |:     .      .     :|      .
                      .      |:L2link      L2link:|      .
                      .      |:     .      .     :|      .
                      . +----+:---+ .      . +---:+----+ .
                      . |   RAN   | .      . |   RAN   | .
                      . +----+:---+ .      . +---:+----+ .
                      .      |:     .      .     :|      .
                      .    +----+   .      .   +----+    .
                      .    | MN |  --------->  | MN |    .
                      .    +----+   .      .   +----+    .
                      +.............+      +.............+

                  Figure 1: Reference Model for Mobile IP

   In 3G CDMA networks, pilot channels transmitted by base stations
   allow the MN to obtain a rapid and accurate C/I (carrier to
   interference) estimate.  This estimate is based on measuring the
   strength of the Forward Pilot Channel or the pilot, which is
   associated with a sector of a base station (BS).  The MN searches for
   the pilots and maintains those with sufficient signal strength in the



Yokota & Dommety        Expires January 10, 2008                [Page 6]

Internet-Draft            3G CDMA Fast Handover                July 2007


   pilot sets.  The MN sends measurement results, which include the
   offsets of the PN code in use and the C/Is in the pilot sets, to
   provide the access network (AN) with the estimate of sectors in its

KC> Is it "AN" or is it "RAN"? Pick a term for consistency.


   neighborhood.  There are several triggers for the MN to send those
   estimates, e.g. when the strength of a pilot in the pilot sets is
   higher enough than that of the current pilot, the MN sends the
   estimates to the access network.  If the serving access network finds
   that the sector associated with the highest pilot strength belongs to
   a different AR, it attempts to close the connection with the MN.  The
   MN then attempts to get a new traffic channel assigned in the new
   access network, which is followed by establishing a new connection
   with the new AR.  The MN can continually search for pilots without
   disrupting the data communication and a timely handover is assisted
   by the network.  If the air interface information can be used as a
   trigger for the handover between access routers, fast and smooth
   handover of Mobile IPv6 can be realized in 3G CDMA networks.

   To assist the handover of the MN to the new AR, various types of
   information can be considered: the pilot sets, which include the
   candidates of the target sectors or BSs, the cell information where
   the MN resides, the serving nodes in the radio access network and the
   location of the MN if available.  To identify the access network that
   the MN moves to or from, the Access Network Identifiers (ANID), which
   is composed of the System ID (SID), Network ID (NID) and Packet Zone
   ID (PZID) can be used [5].  

KC> These parameters are related to 3G 1x CDMA only. for 3G HRPD, parameters like
subnet is used instead. 


   In this document, a collection of such
   information is called "handover assist information".  In 3G networks,
   the link-layer address of the new access point defined in [3] may not
   be available.  If this is the case, the handover assist information
   SHOULD be used instead.






















Yokota & Dommety        Expires January 10, 2008                [Page 7]

Internet-Draft            3G CDMA Fast Handover                July 2007


5.  Fast handover procedures

   There are two modes defined in [3] according to the timing of sending
   FBU (Fast Binding Update); one is called "predictive mode," where the

KC> s/...timing of.../...time of.../

 
   MN sends FBU and receives FBAck (Fast Binding Ack) on PAR (Previous
   Access Router)'s link and the other is called "reactive mode," where
   the MN sends FBU from NAR (New Access Router)'s link.  In the
   predictive mode, the time and place the MN hands off must be
   indicated sufficiently before the time it actually happens.  In
   cellular systems, since handovers are controlled by the network, the
   predictive mode is well applied.  However, if the network is not
   configured to be able to identify the new AR, to which the MN is
   moving next, in a timely manner, the reactive mode is better applied.

5.1.  Predictive fast handover

   Figure 2 shows the predictive mode of MIPv6 fast handover operation.
   When the MN finds a sector or a BS whose pilot signal is sufficiently
   strong, it initiates handover according to the following sequence:

      (a) A router solicitation for proxy router advertisement is sent
      to the PAR.

KC> Does the MN provide any target cell/sector information in this message?

      (b) A proxy router advertisement containing the prefix in the NAR
      is sent back to the MN.

KC> How does the PAR (Previous PDSN) figure out which NAR (New PDSN) the MN
is moving to?


      (c) The MN creates an NCoA (new CoA) and sends the Fast Binding
      Update (FBU) storing the NCoA to the PAR, which in turn sends the
      Handover Initiate (HI) to the NAR.

KC> "...storing the NCoA to the PAR" this part is not clear. Please clarify.

KC> the Previous PDSN (PAR) may send more than one AR-Info (New PDSN info). Which one
does the MN use to create the NCoA?

KC> Please indicate what is done in addition to regular FMIP6 procedures here.



      (d) The NAR sends the Handover Acknowledge (HAck) back to the PAR,
      which in turn sends the FBU acknowledgment (FBAck) to the MN.



      (e) The PAR starts forwarding packets toward the NCoA and the NAR
      captures and buffers them.

      (f) The link-layer connection associated with the PAR is closed
      and a new traffic channel is assigned in the new access network.

      (g) The MN attaches to the new access network.  The attachment
      procedure is access technology specific.

KC> please mention whether the PPP (LCP and NCP) transactions take place here
or not. 


      (h) The MN sends the Fast Neighbor Advertisement (FNA).

KC> s/FNA/UNA/ . Please do this change globally.



      (i) The NAR starts delivering packets to the MN.

      (j) The MN sends the BU to the HA to update the BCE with the NCoA
      and the HA sends back the BA to the MN.  The AAA server may be



Yokota & Dommety        Expires January 10, 2008                [Page 8]

Internet-Draft            3G CDMA Fast Handover                July 2007


      involved for authentication.

KC> AAA server is not involved for authentication of Mobile IPv6 registration if
IKEv2 based SA is used. AAA authentication takes place when PPP (LCP CHAP) is used
to attach to the NAR. 



         MN            PAR             NAR            HA             AAA
         |    RtSolPr   |               |              |              |
    (a)  |------------->|               |              |              |
         |    PrRtAdv   |               |              |              |
    (b)  |<-------------|               |              |              |
         |      FBU     |      Hl       |              |              |
    (c)  |------------->|-------------->|              |              |
         |     FBack    |     HAck      |              |              |
    (d)  |<-------------|<--------------|              |              |
         |              |forward packets|              |              |
    (e)  |              |==============>|(buffering)   |              |
         |              |               |              |              |
    (f) handover        |               |              |              |
         |              |               |              |              |
        +--------------------------------------------------------------+
    (g) |                     Attachment procedure                     |
        +--------------------------------------------------------------+
         |             FNA              |              |              |
    (h)  |----------------------------->|              |              |
         |       deliver packets        |              |              |
    (i)  |<=============================|              |              |
         |              |        BU/BA  |              (Authentication)
    (j)  |<------------------------------------------->|<- - - - - - >|
         |              |               |              |              |

         Figure 2: MIPv6 Fast handover operation (predictive mode)

   It is assumed that the NAR can be identified by the PAR leveraging
   the handover assist information from the MN.  To perform the
   predictive mode, the MN MUST send the FBU before the connection with
   the current access network is closed.  If the MN fails to send the
   FBU before handover, it SHOULD fall back to the reactive mode.  Even
   if the MN successfully sends the FBU, its reception by the PAR may be
   delayed for various reasons such as congestion.  If the NAR receives
   the HI triggered by the delayed FBU after the reception of the FNA
   ((c) comes after (h)), then the NAR SHOULD send the HAck with
   handover not accepted and behave as the reactive mode.

KC> is this behavior defined in RFC4068bis? If so, why are we repeating this here? If
this behavior is not defined in RFC 4068bis, perhaps we should include it there instead.


   In (a), RtSolPr MUST include the MN and the New Access Point Link-
   Layer Address (LLA) options according to [3].  As for the MN-LLA

KC> The term MN-LLA option and AP-LLA option should be defined somewhere. 


   option, the only available identifier is the interface ID, so it
   SHOULD be used for the MN-LLA.  As for the New AP-LLA, the handover
   assist information may be applied.  Since the LLA is assumed to be an
   IEEE identifier, even if the length field of the LLA option is in
   units of 8 octets, the actual length can be obtained by knowing that



Yokota & Dommety        Expires January 10, 2008                [Page 9]

Internet-Draft            3G CDMA Fast Handover                July 2007


   the length of an IEEE identifier is 6 octets.  If the interface ID of
   the MN is generated in the EUI-64-based format, the MN-LLA can be
   constructed from it.  However, if the LLA is not well-known, the
   length of the LLA becomes ambiguous.  If this is the case, it is
   necessary to use a new option defined in Section 6.1 and the
   corresponding length in it.

KC> "if the LLA is not well-known"? Which LLA?

   In (b), PrRtAdv MUST include options for the LLA, IP address and
   prefix of the NAR.  The PAR SHOULD be able to identify the NAR from
   the handover assist information provided by the MN.

KC> Is this the global IP address of the NAR (New PDSN?). Note that in 3G CDMA,
the global IP address of the PDSN is not use by the MN to communicate with the PDSN.
The MN uses PDSN's link local address instead.


   Figure 3 shows the call flow for the initial attachment in 3G CDMA
   network [6].  After the traffic channel is assigned, the MN first
   establishes a link-layer connection between itself and the access
   router.  As the link-layer protocol, PPP can be considered and in
   this figure, a PPP handshake is depicted as an example.  Then the MN
   registers with the HA by sending a Binding Update message.  There are
   several parameters for using Mobile IPv6 such as the home address
   (HoA), the care-of address (CoA), the home agent address (HA) and the
   home link prefix (HLP).  These addresses are required prior to
   sending a Binding Update.  In [6], obtaining these values is called
   bootstrapping and the bootstrapping information is obtained during
   the link-layer establishment phase.

   The procedure for the initial attachment is as follows:


KC> move these call flow steps after the figure.


   (g)    The link-layer connection establishment and the bootstrapping
          phase.

   (g-1)  The LCP configure-request/response messages are exchanged.

   (g-2)  User authentication (e.g.  CHAP or PAP) is conducted.

   (g-3)  The bootstrapping parameters (e.g.  HA, HLP or HoA) are
          conveyed from the AAA and stored in the NAR (target PDSN).

   (g-4)  Unique interface IDs are negotiated in IPv6CP.

   (g-5)  The MN configures its link-local address based on the obtained
          interface ID.

   (g-6)  A router advertisement containing the prefix is received by
          the MN.

   (g-7)  The MN configures its CoA based on the obtained prefix.






Yokota & Dommety        Expires January 10, 2008               [Page 10]

Internet-Draft            3G CDMA Fast Handover                July 2007


   (g-8)  DHCPv6 is used to obtain the bootstrap parameters such as the
          HA, HLP or HoA.

   (g-9)  The MN configures its HoA based on the obtained parameters.
          If a new HoA is provided at (g-8), the MN adopts it (stateful
          auto-configuration); otherwise, the MN generates the HoA based
          on the HLP and its Interface ID (stateless auto-
          configuration).


                 MN            PAR         NAR         HA          AAA
          /       |     (serving PDSN) (target PDSN)    |           |
          |       |        LCP  |           |           |           |
          | (1)   |<----------------------->|           |           |
          |       |        CHAP/PAP         | Access-Request/Accept |
          | (2)   |<----------------------->|<-------------|------->|
          |+........................................+   |  |        |
          |.      |             |    +------------+ .   |  |        |
          |.(3)*  |             |    | HA,HLP,HoA |<-------+        |
          |.      |             |    +------------+ .   |           |
          |.      |                         |       .   |           |
          |.      |    IPv6CP(IF-ID)        |       .   |           |
          |.(4)*  |<---------|------------->|       .   |           |
      (g)< .    +---------+  |  |           |       .   |           |
          |.(5)*| LL-addr |<-+  |           |       .   |           |
          |.    +---------+     |           |       .   |           |
          |.      |                         |       .   |           |
          |.      |       RA(prefix)        |       .   |           |
          |.(6)*  |<---------|--------------|       .   |           |
          |.    +-----+      |  |           |       .   |           |
          |.(7)*| CoA |<-----+  |           |       .   |           |
          |.    +-----+         |           |       .   |           |
          |.      |                         |       .   |           |
          |.      |   DHCPv6(HA,HLP,HoA)    |       .   |           |
          |.(8)*  |<---------------+------->|       .   |           |
          |.    +------------+  |  |        |       .   |           |
          |.(9)*| HoA,HLP,HoA |<---+        |       .   |           |
          |.    +------------+  |           |       .   |           |
          |+........................................+   |           |
          \       |             |           |           |           |

             Figure 3: Attachment procedure in 3G CDMA network

   As is shown in Figure 3, it takes a considerable amount of time to
   establish a link-layer connection and all of the above sequences run
   every time the MN attaches to a new access network.  

KC> Not all sequences will run when the MN attaches to the NAR after handover.
    Step 8 and 9 are not required during handover since the MN already knows those
    information.

KC> In this document, there is no mention of PPP state transfer between PAR and NAR
(Previous PDSN -> New PDSN). Without such optimization, steps 1 - 5 cannot be 
optimized (rather omitted) during inter-PDSN (inter-AR) handover. The benefit of
fast handover will be significantly reduced in that case.



It is therefore
   beneficial if packets on the fly to the MN are saved not only during
   the time period where the MN switches to the new radio channel but



Yokota & Dommety        Expires January 10, 2008               [Page 11]

Internet-Draft            3G CDMA Fast Handover                July 2007


   also during the time period where the MN establishes the link-layer
   connection.

KC> s/...packets on the fly.../...packets in transit.../


   There are several ways to configure a unique IP address for the MN.
   If a globally unique prefix is assigned per each link as introduced

KC> s/...per each/...per.../

   in [6], the MN can use any interface ID except that of the other peer
   to create a unique IP address.  

KC> it seems we are talking about globally unique CoA here. It is not necessary
to have the same CoA sapported at PAR and NAR. It will be rather odd to do that.


If this is the case, however, the PAR
   cannot provide the MN with a correct prefix for the new network since
   such a prefix is selected by the NAR and provided in the router
   advertisement.  

KC> This gets confusing here. Which message are we talking about?


Still, the NCoA MUST be included in the FBU for the
   PAR to resolve the IP address of the NAR, so that the MN configures a
   temporary NCoA with the prefix of the NAR and the correct NCoA MUST
   be assigned by the NAR.  


KC> This isn't any different than base FMIP6. the NAR can always overwrite the
NCoA chosen by the MN. 



Therefore, at step (c) in Figure 2, the PAR
   MUST send the HI with the S flag set when it receives the FBU from
   the MN.  

KC> Please ensure that this is mentioned as a 3G CDMA specific requirement.


On the other hand, if more than one MN connected to an AR
   share the same prefix, each MN MUST have a unique interface ID.

KC> This isn't the case in 3G CDMA. So, please remove this clause.


   Unless it is guaranteed that each MN connected to the network
   including a roaming case is preconfigured with a unique interface ID,
   it MUST be agreed or provided by the NAR via the HI/Hack exchange.

KC> In 3G CDMA, the IID is assigned by the PDSN (AR) to the MN using PPP (IPv6CP).
This IID is guaranteed to be unique only within a PDSN. In case of
handover from PAR to NAR, it may happen that the IID that the MN is assigned 
by PAR (the value that the MN includes in MN-LLA option) is non-unique in the NAR.
This is a problem that needs to be resolved to make this handover procedure work
in 3G CDMA.


   In [3], the FNA MUST include the LLA of the MN, but the point-to-
   point link-layer connection makes it unnecessary.  The only required
   information is the NCoA to check if there is a corresponding buffer,
   thus in (h), the function of the FNA can be realized in several ways.

KC> The above paragraph (needs to change FNA to UNA) gives the impression
that PPP (the p2p link in 3G CDMA) is indeed setup during handover. This assumption
impacts handover performance regardless of handover optimization achieved with
fast handover for MIP6. 



   o  Since the establishment of the link-layer connection in (g)
      indicates readiness of data communication on the MN side, the NAR
      immediately checks if there is a buffer that has packets destined
      for the NCoA and starts delivering if any. (elimination of FNA)


KC> as mentioned, FNA/UNA is much lighter weight than PPP (LCP/NCP). Hence
the elimination of FNA/UNA is actually a disadvantage here.


   o  The FNA equivalent information can be conveyed in the phase of the
      link-layer connection, e.g. by conveying the NCoA in a PPP IPCP
      with vendor specific extension as defined in [8].  Only when this
      message is received by the NAR, it checks if there is a buffer for
      the NCoA.  (L2 implementation of FNA)


   o  The MN sends the FNA as defined in [3] with the LLA of the MN,
      which may be derived from the EUI-64 based interface ID. (standard
      implementation of FNA)

   When PPP IPCP option is used as the means for the L2 implementation
   of FNA, it SHOULD be confirmed that the NAR supports this option,
   otherwise it may cause a longer delay by the Configure-Reject
   message.


KC> The 3G CDMA PDSN's do not support this option. Such option is yet to be defined
in [6].


   The primary benefit of this mode is that the packets destined for the
   MN can be buffered at the NAR, and packet loss due to handover will
   be much lower than that of the normal MIPv6 operation.  Regarding the



Yokota & Dommety        Expires January 10, 2008               [Page 12]

Internet-Draft            3G CDMA Fast Handover                July 2007


   bootstrapping, the following benefits can be obtained, too:

   o  Since the HA, HLP and HoA are not changed during the fast
      handover, bootstrapping information is not required.


KC> It is not required irrespective of fast handover.


   o  Since the NCoA including the interface ID can be obtained or
      configured via the fast handover procedures, a router
      advertisement is not required.

KC> A few questions remain open: How does the MN configure/obtain IID to be
used in NAR? How does the MN know how to populate the AP-LLA option?

   Therefore, the bootstrapping procedures (g-3) to (g-9) can be omitted
   from the standard MIPv6 operation in Figure 3.  

KC> As mentioned before, these procedures are one time things. They are not performed
upon AR-AR handover anyway.


   Also, if the security
   policy permits, the NAR can know the MN by the NAI in the PPP link
   setup and the authentication in (g-2) may be omitted.  Note that
   another authentication is conducted in the MIPv6 registration phase
   and presumably the same AAA is referred to.

KC> NAI information cannot be a replacement of PPP state machine in the NAR. LCP and
NCP phases must be executed between MN and the NAR or PPP context transfer must be performed
between the PAR and the NAR to properly establish link layer between the MN and the NAR. 
MIP6 authentication won't happen upon handover. This is because, the IKEv2 SA won't have 
to be re-established when the MN performs MIP6 re-registration with NCoA. Even in case of
RFC4285, there is no need to re-authenticate the MN at the HA when BU contains NCoA.

5.2.  Reactive fast handover

   When the MN cannot receive the FBAck on the PAR's link or the network
   does not support the predictive fast handover, the reactive fast
   handover can be applied.  To support the predictive fast handover,
   the PAR must accurately resolve the address of the NAR from the lower
   layer information such as the link-layer address of the new access
   point or the base station, which is not always feasible in some
   cases.  

KC> The context should be kept within 3G CDMA networks. Hence, instead of saying,
"in some cases" we should say: in some 3G CDMA networks.

KC> BTW, we are into the Reactive fast handover section. Why are you describing 
issues with the predictive fast handover?



To minimize packet loss in this situation, the PAR instead of
   the NAR can buffer packets for the MN until the MN regains
   connectivity with the NAR.  The NAR obtains the information of the
   PAR from the MN on the NAR's link and receives packets buffered at
   the PAR.  In this case, the PAR does not need to know the IP address
   of the NAR or the NCoA and just waits for the NAR to contact the PAR.
   However, since the PAR needs to know when to buffer packets for the
   MN, the PAR obtains the timing of buffering from the MN via the FBU
   or the lower layer signaling, e.g. an indication of the release of
   the connection with the MN.  Details of the procedure are as follows:

      (a) A router solicitation for proxy router advertisement MAY be
      sent to the PAR.

      (b) The proxy router advertisement MAY be sent to the MN, but the
      prefix of the NAR MAY not be included.

      (c) The MN sends the FBU or the access network indicates the close
      of the connection with the MN by the lower layer signaling.  The
      PAR MAY start buffering packets destined for the PCoA.

KC> s/...network indicates.../...network and indicates.../

      (d) The link-layer connection associated with the PAR is closed
      and a new traffic channel is assigned in the new access network.




Yokota & Dommety        Expires January 10, 2008               [Page 13]

Internet-Draft            3G CDMA Fast Handover                July 2007


      (e) The MN attaches to the new access network.  The attachment
      procedure is access technology specific.  Since the IP address of
      the MN is guaranteed to be unique, the MN SHOULD not perform DAD

KC> the attachment procedure is 3G CDMA specific. Add appropriate references here.

KC> Is there any need to mention DAD and use normative language "SHOULD not" here? 

  
     (f) The MN sends the Fast Binding Update (FBU) to the NAR either
      or not being encapsulated by the Fast Neighbor Advertisement
      (FNA).


KC> If the MN is not doing DAD, why is it doing ND? The FBU can be destined to the PAR
instead of encapsulating it.


      (g) The NAR decapsulates the FBU if encapsulated and sends it to
      the PAR.


KC> There is no need to decapsulate FBU here.


      (h) The PAR sends the Handover Initiate (HI) to the NAR with the
      Code set to 1.

      (i) The NAR sends the Handover Acknowledge (HAck) back to the PAR.

      (j) The PAR sends the FBAck to the NAR.

      (k) If the PAR is buffering packets destined for the PCoA, it
      starts forwarding them as well as newly arriving ones to the NAR.

      (l) The NAR delivers the packets to the MN.

      (m) The MN sends the BU to the HA to update the BCE with the NCoA
      and the HA sends back the BA to the MN.  The AAA server may be
      involved for authentication.


KC> Let's take any AAA dependency out of this document for MIP6 procedures.





















Yokota & Dommety        Expires January 10, 2008               [Page 14]

Internet-Draft            3G CDMA Fast Handover                July 2007


         MN            PAR             NAR             HA            AAA
         |   RtSolPr    |               |              |              |
    (a)  |------------->|               |              |              |
         |   PrRtAdv    |               |              |              |
    (b)  |<-------------|               |              |              |
         |     FBU      |               |              |              |
    (c)  |- - - - - - ->|(buffering)    |              |              |
         |              |               |              |              |
    (d) handover        |               |              |              |
         |              |               |              |              |
        +--------------------------------------------------------------+
    (e) |                    Attachment procedure                      |
        +--------------------------------------------------------------+
         |        FNA[FBU]/FBU          |              |              |
    (f)  |----------------------------->|              |              |
         |              |     FBU       |              |              |
    (g)  |              |<--------------|              |              |
         |              |      HI       |              |              |
    (h)  |              |-------------->|              |              |
         |              |     HAck      |              |              |
    (i)  |              |<--------------|              |              |
         |              |     FBack     |              |              |
    (j)  |              |-------------->|              |              |
         |              |forward packets|              |              |
    (k)  |              |==============>|              |              |
         |        deliver packets       |              |              |
    (l)  |<=============================|              |              |
         |              |        BU/BA  |              (Authentication)
    (m)  |<------------------------------------------->|<- - - - - - >|
         |              |               |              |              |

          Figure 4: MIPv6 Fast handover operation (reactive mode)

   To indicate the PAR to buffer packets destined for the PCoA, in (c),
   the MN SHOULD not include information on the NCoA in the FBU and the
   PAR SHOULD accept it.  Or, when the PAR is indicated that the session
   with the MN has been closed by the lower layer signaling when the PAR
   attempts to send the FBAck, the PAR MAY start buffering.

KC> Suggested re-write:


   In step (c) the MN does not include the NCoA in FBU to indicate to the PAR 
   that it SHOULD buffer packets received for the MN. The PAR also start buffering
   packets for the MN based on lower layer signal during handover.




   An L2-based fast handover is possible as defined in [7] by extending

KC> s/An/A/

KC> Reference [7] does not define fast handover for 3G HRPD. It ony defines
fast handover for 3G 1x.

   the L2 link from the previous access network to the new access
   network via the PAR and the NAR.  The timing of the fast handover
   trigger is the same as the reactive fast handover method (without
   buffering) in this section.  In the case of the L2-based fast
   handover, however, once the L2 link is extended to the new location,
   it is maintained until the MN becomes inactive (dormant) and the link
   is released.  As long as the L2 link is extended, the path, on which
   packets are conveyed, is not optimal in length.  In the case of

KC> not optimal in length? We should rather say....the path may not be 
optimal for real time data transport.



Yokota & Dommety        Expires January 10, 2008               [Page 15]

Internet-Draft            3G CDMA Fast Handover                July 2007


   Mobile IPv6 fast handover, when the new location is registered with
   the HA, the packets are directed to the NAR.

KC> If the large interruption due to PPP setup at the NAR is considered,
the advantage of this solution may seem negligible.



5.3.  Network-controlled fast handover

   If the lower layer can provide necessary information for handover and
   support handover triggering, the fast handover can also be provided
   to MNs that do not support FMIPv6.  RtSolPr, FBU and FNA, which are
   initiated by the MN, may be replaced by such lower layer protocols
   and the fast handover can be performed without explicit involvement
   of the MN.  This type of fast handover has been proposed, for
   example, in [9] and called the network-controlled fast handover in
   this document.  The detailed sequence is shown in Figure 5.

      (a) The MN initiates the handover procedure with the currently
      connected network, which may interact with the new network.  The
      handover intiation procedure is access technology specific.

KC> s/...access technology specific/....3G CDMA specific/


      (b) The PAR (typically) sends the HI to the NAR; however, the NAR
      may instead send the HI to the PAR based on the lower-layer
      interworking.

KC> s/interworking/trigger from the radio access network/


      (c) The AR that received the HI sends back the HAck to the peer
      AR.

      (d) The AR that received the HAck MAY send the Unsolicited HAck to
      the peer AR to confirm the reception of the HAck and/or to send
      access technology specific information.

KC> Response of HAck is Unsolicited HAck?


      (e) The PAR starts forwarding packets to the NAR and the NAR MAY
      buffers them.

      (f) The link-layer connection associated with the PAR is closed
      and a new traffic channel is assigned in the new access network.

      (g) The MN attaches to the new network.  The attachment procedure
      is access technology specific.

KC> In this specific spec, PPP context is transferred from PAR to NAR. Note that
this spec (reference [9]) is not a published spec.

      (h) The NAR starts delivering packets to the MN.

      (i) The MN sends the BU with the CoA being the NCoA to the HA and
      the HA sends back the BA to the MN after successful authentication
      of the BU.  From this time on, the HA starts sending packets
      directly to the MN via the NAR.







Yokota & Dommety        Expires January 10, 2008               [Page 16]

Internet-Draft            3G CDMA Fast Handover                July 2007


         MN            PAR             NAR             HA            AAA
         |              |               |              |              |
        +--------------------------------+             |              |
    (a) |   Lower-layer HO initiation    |             |              |
        +--------------------------------+             |              |
         |              |      HI       |              |              |
    (b)  |              |<------/------>|              |              |
         |              |      HAck     |              |              |
    (c)  |              |<------/------>|              |              |
         |              |    (UHAck)    |              |              |
    (d)  |              |<- - - /- - - >|              |              |
         |              |forward packets|              |              |
    (e)  |              |==============>|(buffering)   |              |
         |              |               |              |              |
    (f) handover        |               |              |              |
         |              |               |              |              |
        +--------------------------------------------------------------+
    (g) |                    Attachment procedure                      |
        +--------------------------------------------------------------+
         |           deliver packets    |              |              |
    (h)  |<=============================|              |              |
         |              |        BU/BA  |              (Authentication)
    (i)  |<------------------------------------------->|<- - - - - - >|
         |              |               |              |              |

           Figure 5: Network-controlled fast handover operation

KC> The HI, HAck, and UHAck arrows should not be bi-directional.
KC> It is not quite clear why this new message called UHAck is needed.


   Even after the MN has moved to the new network, the PAR continues to
   send the packets to the MN by forwarding them to the NAR.  The NAR is
   responsible for delivering packets whose destination address is the
   PCoA to the MN in the new network.  As far as the PAR is involved,
   however, the path from the HA to the MN is not optimal.  In order to
   optimize the path towards the MN, the binding cache in the HA needs
   to be updated.  At an appropriate point after the NCoA has been
   assigned to the MN, the MN sends the BU to the HA to update the
   binding cache in the HA to the NCoA.















Yokota & Dommety        Expires January 10, 2008               [Page 17]

Internet-Draft            3G CDMA Fast Handover                July 2007


6.  Message Format

6.1.  New Option for access-specific handover information

KC> s/...access-specific/3G CDMA specific/


   If the lower layer information of the new point of attachment is not
   represented as the Link-Layer Address, the following option SHOULD be
   used.  The primary purpose of this option is to convey the handover
   assist information described in Section 4.

     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     |  Option-Code  |   AS-Length   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           AS-Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type           T.B.D.

   Length         The size of this option in 8 octets including the
                  Type, Length, Option-Code and AS-Length fields.

   Option-Code    Indicates the particular type of access-specific
                  information.  This value is administrated by the
                  vendor or organization that uses this option.

KC> What are some example Option-Code values? Isn't this 3G CDMA specific? So, why
can't we say that this field is populated by 3GPP2?


   AS-Length      The size of the AS-Value field in octets.

   AS-Value       Zero or more octets of access-specific information
                  data.

KC> What are some example AS-Values?


   This option MUST be understood by the sender (typically the MN) and
   the receiver (typically the AR or the HA).  If nodes in between do
   not support this option, they SHOULD treat this option as opaque and
   MUST not drop it.

KC> Why are we requiring the HA to understand this 3G CDMA access specific values?


   Depending on the size of the AS-Value field, appropriate padding MUST
   be used to ensure that the entire option size is a multiple of 8
   octets.  The AS-Length is used to disambiguate the size of the AS-
   Value.










Yokota & Dommety        Expires January 10, 2008               [Page 18]

Internet-Draft            3G CDMA Fast Handover                July 2007


7.  Security Considerations

   The security considerations for Mobile IPv6 fast handover are
   described in [3].  When a 3G network is considered, the PAR and the
   NAR have a trusting relationship and the links between them and those
   between the ARs and the MN are usually secured.  When the MN is
   authenticated at the phase of the link-layer connection, the AR can
   distinguish the authenticated users from the others.  This may not be
   the case, however, if the access networks are operated by different
   providers.

KC> The last two sentences are not quite clear. Please clarify.










































Yokota & Dommety        Expires January 10, 2008               [Page 19]

Internet-Draft            3G CDMA Fast Handover                July 2007


8.  Conclusions

   The handover performance of the standard Mobile IPv6 is not
   sufficient for real-time communications that are not resilient to
   packet loss.  The Mobile IPv6 fast handover methods are effective for
   these applications.  This document specifies how these methods can be
   applied to 3G networks.  By introducing fast handover, not only are
   more packets saved which otherwise would be dropped, but also some of
   the bootstrapping parameters can be omitted at the link establishment
   phase, which can expedite the handover process.


KC> bootstrapping optimization should be kept out of this conclusion.







































Yokota & Dommety        Expires January 10, 2008               [Page 20]

Internet-Draft            3G CDMA Fast Handover                July 2007


9.  References

9.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Johnson, D., "Mobility Support in IPv6", RFC 3775, June 2004.

   [3]  Koodli, R., Ed., "Fast Handover for Mobile IPv6", RFC 4068,
        July 2005.

9.2.  Informative References

   [4]  3GPP2 TSG-A, "Interoperability Specification (IOS) for cdma2000
        Access Network Interfaces Part 1 Overview", A.S0011-C v.1.0,
        February 2005.

   [5]  3GPP2 TSG-A, "3GPP2 Access Network Interfaces Interoperability
        Specification", A.S0001-A v.2.0, June 2001.

   [6]  3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP
        and Mobile IP services", X.S0011-002-D v.1.0, February 2006.

   [7]  3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Packet Data
        Mobility and Resource Management", X.S0011-003-D v.1.0,
        February 2006.

   [8]  Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.

   [9]  3GPP2 TSG-X, "Fast Handoff for HRPD", X.P0043 v.0.3, 2006.




















Yokota & Dommety        Expires January 10, 2008               [Page 21]

Internet-Draft            3G CDMA Fast Handover                July 2007


Authors' Addresses

   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino
   Saitama,  356-8502
   JP

   Phone: +81 49 278 7894
   Fax:   +81 49 278 7510
   Email: yokota <at> kddilabs.jp


   Gopal Dommety
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   US

   Phone: +1 408 525 1404
   Email: gdommety <at> cisco.com






























Yokota & Dommety        Expires January 10, 2008               [Page 22]

Internet-Draft            3G CDMA Fast Handover                July 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   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 takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr <at> ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Yokota & Dommety        Expires January 10, 2008               [Page 23]


_______________________________________________
Mipshop mailing list
Mipshop <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop