[EMAIL PROTECTED] wrote:
Vijay,
[EMAIL PROTECTED] wrote:
Hi Brian,
Thanks for the review! I have included answers & comments to your
comments below:
3. Service Selection Mobility Option
The Service Selection mobility option MAY be included in
any Binding
Update message. It SHOULD be included at least in the Binding
Update
message that is sent for the initial binding
registration when the
mobile node and the home agent do not have an existing
binding. If
the Binding Update message includes any authorization related
options
(such as the Binding Authorization Data option [1]) or
authentication
related options (such as the Mobility Message
Authentication option
[8]), then the Service Selection option MUST appear before any
mobility message authorization or authentication related options.
(1) I don't understand the SHOULD. Surely the default case (we just
want
basic Internet access) doesn't need this option?
The default case does not need to include the option. In that case
whatever the HA understands as a default behavior &
connectivity gets
applied.
What
about rephrasing:
The Service Selection mobility option MAY be included in
any Binding
Update message. If the Binding Update message includes any
authorization related options (such as the Binding
Authorization Data
option [1]) or authentication related options (such as
the Mobility
Message Authentication option [8]), then the Service
Selection option
when present MUST appear before any mobility message
authorization or
authentication related options.
This is ok, but we still need some text that says, if the
service selection mobility option is used, it needs to appear
only in the initial BU and not required in the BUs sent to
refresh a binding.
IMO Section 4.1 mobile node considerations state this
pretty clearly. Is that enough to be there or should it
also be under the option format description?
I think it is sufficient.
(2) The final MUST could be read in two ways. Does it need
clarifying
thus:
[8]), then the Service Selection option _when present_
MUST appear
before any
mobility message authorization or authentication related options.
Yes. See above.
...
o Identifier: A variable length UTF-8 [3] encoded service
identifier
string used to identify the requested service.
'ims', 'voip' and 'voip.companyxyz.example.com' are valid
examples
of Service Selection option Identifiers. At minimum the
Identifier MUST be unique among the home agents the
mobile node
is
authorized to register to.
(3) Does this mean that a mobile node can request exactly
one service?
Or
is it possible to send more than one Service Selection mobility
option with different identifiers, in order to request access to
several services? If it's restricted to one service, why?
The intention is that only one dedicated service per mobile
ip tunnel
is allowed. This is because the selected service may affect the
allocation of the home address & home network prefix and thus the
routing in the HA. For each mobile ip tunnel we can assign only one
address / prefix.
If we were only after different QoS treatment or filtering
of packets
then multiple options could probably be allowed.
The draft should say something about the number of service
selection
options in the binding update. I would go for maximum one. At least
that was my original idea.
Do we have to say "one"? For example, it might be possible to
provide two different services on the same Mobile IP tunnel.
We could leave this up to folks who might use this option.
Do you mean that we would allow zero or more services in a (P)BU
and then how the HA processes that is up to deployment?
I think it should be possible for the MN to use the same
Mobile IP tunnel for more than one service if both services
are hosted on the same home agent. There might not need be
an immediate need for this, but I think we should support
this from the beginning. So we should allow the mobile node
to include multiple instances of service selection options
in the same binding update.
Vijay
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
