[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE : [DNA] Review of draft-yegin-dna-l2hints-01.txt
Hello Greg,
Find some responses to your comments on draft-yegin-dna-l2hints-01.txt
The responses pertain to the GPRS section
> -----Message d'origine-----
> De : owner-dna@ecselists.eng.monash.edu.au
> [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part de
> Greg Daley
> Envoyé : mardi 22 juin 2004 05:06
> À : Alper Yegin
> Cc : Pekka Nikander; dna@eng.monash.edu.au
> Objet : [DNA] Review of draft-yegin-dna-l2hints-01.txt
>
>
> Hi Alper (CC DNA)
>
> Here is a delayed review of the Link-Hints draft.
> Please feel free to ask me any questions
> regarding the ideas I expressed in the review
> (they are personal opinions only).
>
> Overall, it is a good document, although
> there seems to be a lot of extraneous material which
> is not relevant to the IP layer configuration.
> Since we're referring to other documents, we really only
> need enough context to determine what's happening to
> L3 or L2/L3 interactions.
>
> Please explicitly reference the documents instead
> of having too many details.
>
> Personally, my own view of what hints and triggers
> are has changed over time. While I think the existing
> use of the words are unambiguous within the document,
> it may be worth working out whether there are disparities
> with other documents. This isn't something which can
> be immediately addressed in this draft though.
>
> Greg
> -----
>
>
>
> (S 3.1. GPRS)
>
> Multi-interface terminals are changing the face of wireless IP
> connectivity and GPRS [GPRS] is being one of the most pervasive
> types of radio link for enabling multi-technology access to the
> Internet.
>
> GD: 'is one of the most pervasive [media|types of radio link] for'
>
> GD: Why multi-technology??? Is this a necessary statement when
> GD: describing GPRS for DNA?
>
> GPRS is an enhancement to the GSM data transmission
> architecture and
> capabilities, designed to allow for packet switching in user data
> transmission within the GPRS network as well as for higher quality
> of service for the IP traffic of Mobile Terminals with external
> Packets Data Networks (PDN) such as the Internet or
> corporate LANs.
>
> GD: sentence too long. This needs to be broken into smaller pieces.
> GD: Also, I'm not sure where QoS comes in (may be distracting
> GD: to the context - which is DNA) I've not read the rest of the
> GD: document yet, but please consider removing it:
> GD: perhaps:
>
> "GPRS is an enhancement to the GSM data transmission
> architecture and capabilities. It is designed to allow for
> packet switching and transmission within the [GSM? | GPRS]
> network, as well as provide quality of service for mobile
> terminals connected to the Internet or corporate network."
>
> ...
>
> - An IP Core Network that acts as the transport backbone of user
> datagrams between SGSNs and Gateway GPRS Support Nodes (GGSN). The
> GGSN ensures the GPRS IP core network connectivity with external
> networks, such as Internet or Local Area Networks.
>
> GD: I'm not sure that this is really a relvant statement since the
> GD: network is an opaque tunnel from the point of view of the
> GD: mobile stations. It may be worthwhile indicating that packets
> GD: traversing the core only see a single IP hop.
Actually this was meant to introduce GPRS to the DNA community before indicating the GPRS link layer hints and facilitate their comprehension. But agree that the details may not be relevant for DNA.
>
> From the point of view prevailing in detecting network
> attachment, the GPRS access network will be only seen as
> providing layer 1-2 reachability even if it is able to
> provide IP connectivity alone.
>
> GD: This is not adequately explained without discussing the tunneling,
> GD: if the core network is being described as connected to
> the internet.
> GD: The readers aren't necessarily aware of GPRS's architecture.
>
Could you make this clearer?
>
> (S 3.1.2. Link-layer Events and Information)
>
> In GPRS networks, only network attachment/detachment and
> subsequent
> PDP context changing events will directly impact the IP
> configurations, hence should be used as link-layer triggers by IP.
> Other events such as routing area and cell change do not directly
> imply potential configuration change. More details on those
> secondary types of events can be found in Appendix A.
>
> GD: It's not clear from reading below that GPRS attach actually
> GD: affects IP connectivity at all, except where it allows
> GD: signalling and tunneling messages to reach the GGSN.
> GD: I think that the PDP context is far more important, although I
> GD: may be misleading myself. Obviously GPRS detach may cause IP layer
> GD: state change, too.
>
PDP context activation/deactivation is effectively far more important but attachment/detachment was mentionned as the necessary link-layer connectivity operation
>
> When a MT has performed the GPRS attach, it becomes in
> READY state.
>
> GD: it [goes to|moves to] READY state.
>
> In this state, the MT is reachable (using the logical link layer -
> LLC) by the GPRS Radio Access Point called the SGSN.
> Otherwise, its
> state is said to be IDLE. During the IDLE state, no IP level
>
> GD: I think I understand what's going on, but am not sure.
> GD: are there two states? one for LLC and one for IP PDP?
> GD: or are these two different mutually exclusive states?
> GD: I think this needs to be clear and explicit.
GPRS has three operationnal states
IDLE: station not attached to the GPRS network
READY state: station attached and is communication/has been communicating "recently"
STANDBY state: station moves to STANDBY state when a timer indicates no activity (data or signalling) for a given period of time in READY state.
So the states do not strictly refer to operation performed (attachment, PDP contect activation)
Hope this is clearer
>
> communication is possible with an external network, such as
> Internet. The SGSN identifies the logical link with the MT by the
> Temporary Logical Link Identifier (TLLI) it derives from
> the P-TMSI
> that was assigned to the MT. It has to be noted that the
> MT or SGSN
> may initiate a detach procedure (Mobile or Network Initiated
> Detach). The MT returns from READY to IDLE STATE upon detachment.
>
> The MT is actually considered GPRS attached when it has
> received an
> "Attach Accept" message from the SGSN. The MT is
> considered detached
> from the GPRS Network when it has sent or received a
> "Detach Accept
> message" from/to the SGSN. This is an indication that the
> link-layer
> connectivity is being lost.
>
> GD: Indeed. I can't see what the GPRS attach indicates to the
> GD: IP layer though.
Refer to previous response. Effectively, we will consider dropping it and restrict ourselves to indications directly having consequence on IP layer to be in line with the scope of DNA.
>
> ...
>
> A MN that wants to establish IP-level connections through the GPRS
> MT should first request the GPRS network to settle the necessary
> soft state mechanism (GPRS tunneling protocol) between its serving
> SGSN and the GGSN corresponding to the APN specified in the PDP
> Context parameters. Only after this tunneling mechanism
> takes place
> can the MN's IP packets be forwarded to and from its remote IP
> peers. The process by which this is made possible is
> designated as a
> PDP Context Request.
>
> GD: This is the only time APN is used except for in the
> terminology section
> GD: please consider also providing the long form here.
> GD: Is the process of getting a PDP context called PDP
> context activation
> GD: or a PDP context request? please check.
>
> ....
A PDP context is considered established when an "activate PDP ontext accept" is received on the station
>
> The network may also decide to modify an existing PDP
> Context with a
> given MN at any time. Such a modification might be prompted by the
> MN's serving SGSN when it estimates that the negotiated
> QoS profile
> can no longer be respected. For instance, the GPRS Network might
> temporarily not be able to guarantee the contracted
> delay, in which
> case it would force the related PDP context parameter to be
> renegotiated. Note that, a MT can decide not to accept such an
> update of its PDP context, in which case it should start a PDP
> context deactivation procedure. Furthermore, a PDP context may be
> deleted at any time at the request of the MT or the
> network. After a
> PDP context is deleted, the MT returns to simply attached state
> (READY STATE). Finally, a Mobile Terminal can hold several PDP
> contexts, each corresponding to a different NSAPI.
>
> GD: For the text near "Note that, " in this case, no triggers/hints
> GD: would be generated.
If the station decide not to accept the update of the context with the suggested profil, it will put an end to the pDPD context and therefore triggeers need to be caught!
> GD: Perhaps it is better to just indicate that a trigger
> GD: would be generated if there was a GPRS Detach while there were
> GD: open PDP contexts
agree
(rather than mention states which don't
> GD: generate triggers)
>
>
> GD: Overall, this section ends well.
> GD: I think that there is a lot of extraneous discussion of
> GD: GPRSisms which don't impact (or don't even have parameters
> GD: which directly impact) IP connectivity at all.
> GD: Focussing only on that which will have impact on IP, or
> GD: which passes (relevant) parameters to IP is a good way to
> GD: shorten this.
Understood. Will work this out with the editor and submit relevant changes sections.
Eric Njedjou
>