[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 3gpp-analysis-04: Editorial issues
Hi, Pekka!
Many thanks for your comments, some comments below
marked with JW.
-----Original Message-----
From: ext Pekka Savola [mailto:pekkas@netcore.fi]
Sent: 21 July, 2003 15:55
I've looked a bit into 3GPP Analysis document, and I'll be sending out
issues I found out separated in different messages, a day or so apart.
<chair hat on>
Whether they should be filed in an issue tracker (like
Roundup), a web page, etc. is up to the 3GPP design team, and especially
the editor.
</chair hat off>
JW: Using the tracker is a good idea, I consider that after my holidays.
editorial
---------
This document analyzes the transition scenarios in 3GPP packet
data networks that might come up in the deployment phase of IPv6.
The transition scenarios are documented in [3GPP-SCEN] and this
document will further analyze them. The scenarios are divided into
two categories: GPRS scenarios and IMS scenarios.
==> first use of "IMS", so spell it out.
JW: Yep.
1.1 Scope of this Document
The scope of this informational document is to analyze and solve
the possible transition scenarios in the 3GPP defined GPRS network
==> note that the category will be BCP, so perhaps it's better to
substitute s/informational/Best Current Practices/, or even "informational
Best Current Practices/, as you prefer considering the audience (i.e.
whether they're aware of what BCP really means)
JW: That's correct, I will use BCP.
where a UE connects to, or is contacted from the Internet, or
==> s/from/from,/, s/Internet,/Internet/ ?
JW: Hmm, good question is, whether any commas are needed in that
sentence at all - can any native speaker confirm?
of the SIP based IP Multimedia Core Network Subsystem (IMS). This
document is not focused on radio interface issues; both 3GPP Second
==> s/is not focused/does not focus/ ?
JW: ok
1.2 Abbreviations
==> I note that SGSN, HLR and DNS (at least) are not listed. At least the
first two should be added.
JW: Yes, the abbreviations HLR and SGSN (mentioned only once) are missing,
and so is DNS also. I will add all three, and check the doc through for
any other missing abbreviations.
1.3 Terminology
Dual Stack UE Dual Stack UE is a 3GPP mobile handset having dual
stack implemented. It is capable of activating
both IPv4 and IPv6 PDP contexts. Dual stack UE may
be capable of tunneling.
==> there is a slight circular definition here, "DS UE is something with
dual stack". Maybe some rewording would be needed? Not a major issue.
JW: Yep, dual stack has dual stack... I'll make some rewording, such as
the UE has both IPv4 and IPv6 stacks.
This chapter briefly introduces some transition mechanisms
specified by the IETF. Applicability of different transition
mechanisms to 3GPP networks is discussed in chapters 3 and 4.
==> s/Applicability/The applicability/ ?
JW: That can be correct...
The following scenarios described by [3GPP-SCEN] are analyzed here.
In all of the scenarios, the UE is part of a network where there is
at least one router of the same IP version, i.e. GGSN, and it is
connecting to a node in a different network.
==> s/it is/the UE is/
JW: got it.
In this scenario, the dual stack UE is capable of communicating
with both IPv4 and IPv6 nodes. It is recommended to activate an
IPv6 PDP context when communicating with an IPv6 peer node and an
==> spell out PDP.
JW: PDP context needs to be spelled out. I will do it already in section 2.1 or even in 1.3.
However, the UE may attach to a 3GPP network, in which the SGSN
(Serving GPRS Support Node), the GGSN and the HLR (Home Location
Register) support IPv4 PDP contexts by default,
==> change the order of term and abbreviation:
Serving GPRPS Support Node (SGSN), Home Location Register (HLR)
JW: You mean alphabetical order? Anyway, I would like to list the
network elements in a more logical order, according to their functionalities.
One deployment scenario example is using laptop computer and a UMTS
UE as a modem.
==> s/laptop/a laptop/
==> I don't think UE is a modulator/demodulator and calling it a modem
may be a bit confusing ?
JW: 1. ok, 2. That is the common language used, e.g. GPRS phones are shown
as modems and AT commands are used for contorl. Another term we could
use is dial-up (emulation).
When analyzing a dual stack UE behavior, an application running on
a UE can identify whether the endpoint required is an IPv4 or IPv6
capable node by examining the address to discover what address
family category it falls into.
==> reword "application": typically, this function is performed at a lower
layer (operating system, IP stack), and the use of applciation gives IMHO
the wrong picture that the applications themselves would have to somehow
distinguish the end-point address family.
JW: Hmm, some applications can participate in that decision making?
But what kind of rewording would you suggest?
==> s/category//
JW: got it.
Since the UE is capable of native communication
with both protocols, one of the main concerns of an operator is
correct address space and routing management.
==> s/correct/the correct/ ?
JW: ok
Keeping the Internet name space unfragmented is another important
issue for both IPv4 and IPv6. It means that any record in the
public Internet should be available unmodified to any nodes, IPv4
or IPv6, regardless of the transport being used.
==> s/any record/any DNS record/ (maybe even spell out DNS)
JW: DNS record sounds good.
served by at least an IPv4 reachable DNS server. This
==> s/an/one/
JW: yup.
be used. In a 3GPP network, one IPv6 island could contain the GGSN
while another island contains the operator's IPv6 application
servers. However, manually configured tunnels can be an
==> s/contains/could contain/
JW: I would put "can contain" to both.
"6to4" nodes use special IPv6 addresses with a "6to4" prefix
containing the IPv4 address of the corresponding "IPv6 in IPv4"
tunnel endpoint ("6to4" router) which performs encapsulation /
decapsulation. When connecting two nodes with "6to4" addresses, the
==> s/"6to4"/6to4/ (could explain it the first time 6to4 is stated if
necessary)
JW: Yep, actually those quotation marks are not needed, I will spell out 6to4
when it pops up for the first time.
3.3 IPv4 UE Connecting to an IPv4 Node through an IPv6 Network
3GPP networks are expected to support both IPv4 and IPv6 for a long
time, on the UE-GGSN link and between the GGSN and external
networks. For this scenario it is useful to split the end-to-end
IPv4 UE to IPv4 node communication into UE-to-GGSN and GGSN-to-
v4NODE. An IPv6-capable GGSN is expected to support both IPv6 and
IPv4 UEs. Therefore an IPv4-only UE will be able to use an IPv4
link (PDP context) to connect to the GGSN without the need to
communicate over an IPv6 network. Regarding the GGSN-to-v4NODE
communication, typically the transport network between the GGSN and
external networks will support only IPv4 in the early stages and
migrate to dual stack, since these networks are already deployed.
Therefore it is not envisaged that tunneling of IPv4 in IPv6 will
be required from the GGSN to external IPv4 networks either. In the
longer run, 3GPP operators may need to phase out IPv4 UEs and the
IPv4 transport network. This would leave only IPv6 UEs. Therefore,
overall, the transition scenario involving an IPv4 UE communicating
with an IPv4 peer through an IPv6 network is not considered very
likely in 3GPP networks.
==> the paragraph is too long and should be reorganized slightly so that
it can be split to two or more paragraphs.
JW: The paragraph is not that long, but because it is the
whole section, I'll do it.
However, since it is difficult to anticipate all possible
applications, there is a need for translators that can translate
==> s/all/all the/
JW: ok
2. Additional forwarding delays due to further processing, when
compared to normal IP forwarding.
3. Problems with source address selection due to the inclusion of
a DNS ALG on the same node [NATPT-DNS].
==> start these with "There are ..."
JW: fine for me. However, parts of that text may be removed once
we can refer to NAT-PT appl- statement doc.
Furthermore, high reliability is expected for 3GPP networks.
Consequently, a single point of failure on the GGSN external
interface, would raise concerns on the overall network reliability.
==> s/interface,/interface/
JW: ok
The legacy IPv4 nodes are mostly nodes that support the
applications that are popular today in the IPv4 Internet: mostly e-
mail, and web-browsing.
==> s/mail,/mail/
JW: ok
applications. As these application are designed for IPv6, and to
use the advantages of newer platforms,
==> s/application/applications/
JW: good point.
Taking the above into account, the traffic to and from the legacy
IPv4 UE is restricted to a few applications. These applications
already today mostly rely on proxies or local servers to
communicate between private address space networks and the
Internet.
==> remove "today" from "already today mostly rely" (too complex otherwise
:-)
JW: OK, this is not an EU directive document, will do something to it.
4. IMS Transition Scenarios
As the IMS is exclusively IPv6, the number of possible transition
scenarios is reduced dramatically. In the following, the possible
transition scenarios are listed.
==> reword: (or something to the effect).
JW: I try to do something.
As the IMS is exclusively IPv6, the number of possible transition
scenarios is reduced dramatically and are listed below.
The recommended approach (as documented in [DNStrans]) currently is
that every recursive DNS server should be either IPv4-only or dual
==> s/currently is/is currently/ ?
JW: I'd keep the order as it is.
stack and every single DNS zone should be served by at least an
IPv4 reachable DNS server. The recommendation rules out IPv6-only
==> s/an/one/
JW: got it
There will probably be few legacy IPv4 nodes in the Internet that
will communicate with the IMS UEs. It is assumed that the solution
described here is used for limited cases, in which communications
with a small number of legacy IPv4 SIP equipment are needed.
==> did you really mean "few" (like, "hardly any"), or "a few" ?
JW: Our intention was to say, that the number of legacy IPv4 SIP
nodes that need to communicate with IMS UEs probably is (really) small, so
few is correct.
Figure 1 shows a possible configuration scenario where the SIP ALG
is separate to the CSCFs.
==> s/separate to/separated from/ (or something else, I'm not sure what
the text is intended to mean) ?
JW: At least "separated from" sounds good. I don't actually know whether
"separate to" is incorrect..?
The authors notify that work is being done on analyzing 3GPP
IPv4/IPv6 translators related to IMS scenario 1, and a personal
draft is expected shortly.
==> note that the IMS scenario 1 is really *this* scenario, should this be
reworded?
JW: I will reword that anyway and tell about Karim's draft.
7. Copyright
==> please also add the IPR section
JW: Yep, can add that, even though we don't have any IPRs on this doc.
Is it a needed section in every draft / RFC?
8. References
8.1 Normative
[RFC2327] Handley, M., Jacobson, V.: SDP: Session Description
Protocol, RFC 2327, April 1998.
[RFC3266] Olson, S., Camarillo, G., Roach, A. B.: Support for IPv6
in Session Description Protocol (SDP), June 2002.
==> are these meant as normative references? No harm in having them, I
guess, but I guess they're more like informational in nature..
JW: It was easy putting them as normative references, because they are
RFCs. As you commented. those RFCs contain relevant background information for
IMS scen 1 / SIP functionality related to that. But anyway, we are not considering
SIP parts that deeply.
[ISP-scen] Mickles, C. (Editor): "Transition Scenarios for ISP
Networks", March 2003, draft-mickles-v6ops-isp-cases-05.txt, work
in progress.
==> replace by Mikael Lind's document (I think)
JW: Yep, needs to have the latest doc.
[ISP-analysis] Mickles, C. (Editor): "Transition Analysis for ISP
Networks", February 2003, draft-mickles-v6ops-isp-analysis-00.txt,
work in progress.
==> this should be removed for now (I think)
JW: Yes, at least until Lind's team manages to puglish their -00 analysis.
I will start my 3,5 week holiday on Tuesday afternoon and will be back on week
34. I will produce a new version of our document that week. Hopefully other
members in the design team can reply to the comments sent on the
mailing list.
Cheers,
-Juha-