Margaret Wasserman wrote:
>>>> Therefore, while the host must support Neighbor
>>>> Solicitation and Advertisement messages, their use
>>>> in address resolution and next-hop determination is
>>>> not necessary and the host may choose to not initiate
>>>> them.
>>>>
>>>I don't think that we should include the last sentence of
>>>this paragraph.
>>>
>>Can you detail what your objection to the last sentence is?
>
> Saying that a host "may choose to not initiate" NUD messages is
> the same thing as saying that a host may choose not to comply with
> the NUD portions of RFC 2461, which clearly indicates that hosts send
> NUD-related NA and NS messages in certain situations, such as when
> an IPv6 packet is sent to/through a neighbor whose neighbor cache
> entry is in the PROBE state.
Ok, but this text fragment was not attempting to say anything about NUD,
that's why it explicitly said "in address resolution and next-hop
determination". But I can see that it can be interpreted the other
way. How about the following:
2.4 RFC2461 - Neighbor Discovery for IPv6
Neighbor Discovery is described in [RFC-2461]. This
specification is a mandatory part of IPv6.
2.4.1 Neighbor Discovery in 3GPP Networks
Hosts must support Neighbour Solicitation and
Advertisement messages.
In GPRS and UMTS networks, some Neighbor Discovery
messaging can be unnecessary in certain cases.
GPRS and UMTS links resemble a point-to-point link;
hence, the host's only neighbor on the cellular
link is the defaul router that is already known
through Router Discovery. Therefore, while the
host must support address resolution and next-hop
determination, the host may choose to not initiate
these tasks.
So hopefully this covers part of the problem. We still have to
deal with NUD. We already stated earlier that NUD is mandatory.
My understanding is that the discussion relates to the
kind of advice we can give to NUD for the suppression of
the messages:
1) From the PDP context positive feedback all
the way up to and including a working GGSN IP layer,
even if this is strictly speaking lower layer from the
point of view of the cellular host.
2) From the upper layers, without mentioning specifics.
Basically exactly what RFC 2461 says.
3) From the upper layers, with some specific 3GPP
guidance. For instance, SIP is heavily used over UDP.
It might make sense to state that a SIP application
should give the progress information it has to the
UDP layer (which doesn't get any progress information)
so that it can tell this information to IP.
Margaret, I do see the problem you described in your e-mail
about getting to the PROBE state, but as far as I can see,
the current proposal was to use suppress NUD *only* if you
got positive feedback. So, in your problem example the
host would actually get positive feedback and the entry
would be kept in the REACHABLE state.
The remaining question is whether the source of the feedback
can be 1, 2, or 3. Let me propose that we pick either 1 or 3.
Assuming 1 is ok, the following text would appear to do the
job:
The host must support neighbour unreachability
detection as specified in [RFC-2461].
In GPRS and UMTS networks, it is very desireable to
conserve bandwidth. Therefore, hosts stacks used in
these environments should include a mechanism in
other layer protocols (such as TCP or PDP Context)
to provide reachability confirmation when two-way
IP layer reachability can be confirmed (see RFC-2461,
section 7.3.1). These confirmations will allow the
suppression of most NUD-related messages.
Assuming 3 is ok, the following text discusses a bit more
into the details regarding the upper layers in typical
3GPP hosts:
The host must support neighbour unreachability
detection as specified in [RFC-2461].
In GPRS and UMTS networks, it is very desireable to
conserve bandwidth. Therefore, hosts stacks used in
these environments should include a mechanism
in upper layer protocols to provide
reachability confirmation when two-way IP layer
reachability can be confirmed (see RFC-2461,
section 7.3.1). These confirmations will allow the
suppression of most NUD-related messages.
Host TCP implementation should provide
reachability confirmation.
The use of UDP for many purposes in 3GPP
networks poses a problem for providing this
reachability confirmation. UDP itself is
unable provide such confirmation. Instead,
applications running over UDP should provide
the confirmation where possible. In particular,
when UDP is used for transporting RTP, the RTCP
protocol feedback should be used as a basis for
the reachability confirmation. When UDP is used
for transporting SIP, responses to SIP requests
should be used as the confirmation.
Jari
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
