Hello all, Last week (26-30 November) took place the 3GPP SA2 #21 meeting in Cancun. At this occasion I presented a discussion paper introducing draft-wasserman-3gpp-advice-00.txt to the 3GPP community. This Internet-draft was generally well received, however 3GPP SA2 will wait until the IPng WG has endorsed it before deciding whether to follow any of the recommendations and introduce any changes in the 3GPP standards.
Following this presentation, and to keep up the co-operation between IETF and 3GPP, we set up a small drafting group of interested people with the objective of putting forward a number of suggestions for improvement, as well as some questions about this draft, to the IPng working group. These comments are included below. (Sorry for the long email) Let me take this opportunity to congratulate the members of the IPng design team for their good and constructive job in producing this Internet-draft and also stress that a quick resolution on the acceptance of this I-D by the IPng WG is required in order to get a chance to have any necessary changes (if accepted by 3GPP) introduced in the next 3GPP release, i.e. R5, which is due for completion in March 2002 and is a major milestone for IPv6 in 3GPP. Regards, Juan General comments: ---------------- 1) It would be useful to include some description/guidelines about how IPv6 address blocks should be allocated to 3G mobile operators (i.e. what size, possibility to get additional address blocks if needed and how, etc.), in particular considering that in some countries operators with more than 100 millions subscribers, possibly using multiple "primary" PDP contexts, are foreseeable. It is probably not IPng's task to define these policies, however some hints or references to other RFCs might reveal useful for telecom operators that do not necessarily read all these RFCs. 2) Would the /64 prefix allocation preclude the use of the 6to4 transition mechanism in 3GPP? 6to4 relies on a /48 prefix, meaning that only 64k mobile nodes (or rather "primary" PDP contexts) would be allowed on a given APN that supports 6to4. Detailed comments: ----------------- 3) Section 6.5 applies to 3GPP Release 99; this should be explicitly stated, as in later releases (i.e. in Release 5) the architecture is further evolved, for instance by introducing the IP multimedia subsystem or other changes to existing procedures. 4) The APN concept is missing in section 6.5 (but is mentioned in the Appendix). "APN = Access Point Name" should also be added to the 3GPP terminology section. Suggested text: "The APN is a logical name referring to a GGSN. The APN also identifies an external network. The syntax of the APN corresponds to a fully qualified name. At PDP context activation, the SGSN performs a DNS query to find out the GGSN(s) serving the APN requested by the terminal. The DNS response contains a list of GGSN addresses from which the SGSN selects one (in a round-robin fashion)." 5) Section 6.5.2 says: "There are two kinds of PDP Contexts -- primary, and secondary". There seems to be a slight misunderstanding of the concept of multiple PDP contexts, i.e. once activated, all PDP contexts associated with the same IP address are conceptually equal; the MS can delete a "primary" PDP context and keep the "secondary" ones. But since the idea of "primary" and "secondary" PDP context provides an easy understanding of the problem it is probably good to keep this terminology. However, for a better clarity, here is some suggested rewording: In 6.5.2, "In addition, one or more secondary PDP Contexts can be added to a primary PDP Context <and share the same IP address>." Also add at the end of 3rd paragraph of 6.5.2 "Once activated, all PDP contexts have equal status, meaning that a primary PDP context can be deleted while keeping the link between the UE and the GGSN, as long as there are other (secondary) PDP contexts active for the same IP address." Still in 6.5.2 the description of Deactivate PDP Context should read "Deactivates a PDP Context. If a primary PDP Context <and all secondary PDP contexts associated with it are> deleted, a link between the UE and the GGSN is removed." 6) In section 6.5.3 (and other places), the last paragraph says that the IP address of the MS is used in the SGSN to identify the PDP context associated with each packet; this is not correct. Packets are tunnelled in GTP between the RNC, SGSN and GGSN and are routed based on the TEID. The IP address is only used by the GGSN to identify the PDP context; in the SGSN, the IP address can be used for charging (or legal interception) purposes. Suggested text: Add "GTP-U = GPRS Tunnelling Protocol - User plane" to the 3GPP terminology. In 6.5.1 add "GTP-U is a simple tunnelling protocol running over UDP/IP and used to route packets between RNC, SGSN and GGSN within the same, or between different, UMTS backbone(s). A GTP-U tunnel is identified at each end by a Tunnel Endpoint Identifier (TEID)." In 6.5.3, last paragraph, reword as "... so that the SGSN can know the single address of each 3GPP node (e.g. for charging purposes). This address is used <in the GGSN> to identify ..." 7) Section 7.3, second paragraph: In the second paragraph, what was the intention of "or more"? It should be clearer that the recommendation to allocate a /64 prefix to each primary PDP context is independent of whether one or multiple prefixes are allowed per PDP context (indeed, due to time constraints 3GPP might not be able to support multiple prefixes per PDP context in the coming 3GPP release, but could at least support prefix allocation). Perhaps "or more" should be put in parenthesis. 8) Section 7.3.2 also states that SGSN uses the IP address to identify the PDP contexts (see comment #6 above). The corresponding sentence should simply be removed. Also in the next to last paragraph of 10.1, the last sentence should rather read "By assigning a given prefix to only one primary PDP context, the SGSN can <associate this prefix list with> the PDP contexts." 9) Section 10.1, last paragraph: It is stated that the devices behind the MT can activate their own primary PDP contexts. Without entering into details, it is not the device behind the MT that activates a PDP context, but the MT itself on request from the device (or by some automatic means). Suggested text: "However this is not necessary if each device behind the MT is connected to a separate primary PDP Context ..." -------------------------------------------------------------------- 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] --------------------------------------------------------------------
