[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
3gpp-analysis-04: Editorial issues
Hi,
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>
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.
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)
where a UE connects to, or is contacted from the Internet, or
==> s/from/from,/, s/Internet,/Internet/ ?
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/ ?
1.2 Abbreviations
==> I note that SGSN, HLR and DNS (at least) are not listed. At least the
first two should be added.
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.
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/ ?
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/
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.
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)
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 ?
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.
==> s/category//
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/ ?
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)
served by at least an IPv4 reachable DNS server. This
==> s/an/one/
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/
"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)
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.
However, since it is difficult to anticipate all possible
applications, there is a need for translators that can translate
==> s/all/all the/
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 ..."
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/
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/
applications. As these application are designed for IPv6, and to
use the advantages of newer platforms,
==> s/application/applications/
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
:-)
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).
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/ ?
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/
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" ?
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) ?
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?
7. Copyright
==> please also add the IPR section
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..
[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)
[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)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings