There is a big editorial choice ahead, IMO, which is whether some "Access
Networks" specific stuff (about everything except under core/backbone and
IXP sections) should be "aggregated" somewhere. That is, there seems to
be no use repeating the same thing 5 times (e.g. about user
authentication, access routers, hosting gear, web caching infrastructure
etc.etc.), and only report the connectivity-specific stuff under the
appropriate sections.
Comments below.
Substantial:
------------
Status of this Memo
This document is an Internet-Draft and is subject to all
Provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
==> Here and elsewhere: the editorial quality and conformance to typical
format must improve. For example, in a lot of places, paragraphs should
be separated by empty lines, etc. Doing that makes reading the doc *a
lot* easier.
==> I will make some direct contributions, if no one else comes first,
when the situation has improved.
___|___ ___|__ ___|___
| | | | | |
| CPE1 | | CPE2 | | CPE(n)|
|_______| |______| |_______|
==> These should be named "Customer1", .. (n). Also in this section,
issues about CPE's etc. should really be split off: such should be dealt
under the appropriate access network scenarios section.
==> I'm not certain how to best handle the generic "layer" between all the
access methods: there are certainly a lot of common elements, does
everything have to be repeated N times? That's something which one may
have to consider (e.g. whether to create "Access Networks" abstraction
layer explaining the generic stuff)
4.1 Topology
==> This, and some scenarios above, are too "core/edge" -separation
centric. There are a lot of networks which only include bigger and
smaller edge devices, some of which are more geared to "core-like"
operation while others are not. One such "all edge" network, for example,
is GEANT (http://www.geant.net/geant/about-geant.html).
4.3.2 EGP
Generally BGP4 is the Edge gateway protocol of choice. The EGP
routing table consists of networks, which are received via
customer advertisements, statically configured for customers who
are not running a dynamic routing protocol or networks that are
nailed up as part of the ISP infrastructure.
==> It is also common practise to redistribute static routes, through
safety checks of a route map. This is particularly enticing if the
customer routes are part of larger aggregates, that is, even if the
customer link flaps, no BGP updates/withdrawals are propagated to the
Internet, only to the internal topology of the ISP.
4.3.4 Multicast
PIM-SM is the generally accepted solution for deploying multicast.
==> a lot of stuff should be added here in the future, on PIM, MBGP, MSDP,
RP's, BSR, whether customers use your RP, etc.etc. I could contribute
something even.
4.5. Security
==> protecting routers (e.g. access lists that prevent telnet/ssh access,
other methods, account management, etc.) should be described.
4.5.1 Intrusion Detection
Intrusion detection mechanisms and systems are used to protect
infrastructure and host gear. Generally these intrusion
detection systems are placed at various points within the network
to search for vulnerabilities within the infrastructure as well
as monitor activity that may be considered suspicious.
==> what infrastructure you're talking about? Certainly, I think it's
quite rare to see IDS systems deployed to protect routers. They're more
of protecting the management systems which are used to control the
network, if anything.
4.5.2 Ingress Filtering
Ingress filtering on CORE networks comes in multiple flavors.
For providers that do filter, the first level is EGP filtering.
When a peering session is setup, ISPs require a peer to register
their routes in an IRR and that data is used to create an EGP
filter on the peering session to only accept registered
advertised routes.
==> there are also manually configured access lists, e.g. lists that
disallow any more specifics from your aggregates (inbound or outbound).
Of course, with todays errant multihoming practises, this may not be
possible for some ISP's.
==> speaking of which, one should probably spend some time describing
mechanisms which are used for multihoming the backbone network (trivial)
and multihoming the customers (more related to access networks).
Customer Premises NAP NSP
<-------------------------> <---------------> <-------------------->
+-----+ +-------+ +-----+ +--------+ +-----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ ISP | ISP
+-----+ +-------+ |Modem| +--------+ | Edge +==> Network
+-----+ | Router |
+-----------+
<---------------------------->
ATM
Customer Premises NAP NSP
<--------------------> <----------------------> <----------------->
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
|
+-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM +-+ BAS +-+ ISP |
+-----+ +-------+ +--------+ +----------+ | Edge +=>Core
| Router |
+-----------+
<-------------------------->
PPP
==> some DSL figures include DSL model while others don't. Sync that up.
(Note: I've mentioned this before, too, I'm getting tired of repeating
myself.)
7.2. Hardware
The hardware involved in dialup service provider connections
include the CPE device that is usually a 56K modem, the Terminal
server/modem bank and an authentication server.
==> also in some other places, I believe "narrowband" also applies to ISDN
connections.
+----------+ +-------+
| IP | | IP |
+----------+ +-----------+ +-------+
| Wireless | | Bridging | | | |
| LAN | +-----------+ | X | Y |
| | |WLAN | X | | | |
+----------+ +-----+-----+ +---+---+
==> the model of WLAN section seems to build on the fact that AP acts as a
bridge. This is not necessarily the case. AP can also be a router (when
AP and router are co-located).
8.4 Security
==> Note that even 801.11x with extensions does not give protection; there
is always the issue of a host and AP being certain that they are in fact
talking to each other (a man-in-the-middle attack). Not sure if this
needs to said in the draft (and this is why why some e.g. force the use of
VPNs usings IPsec in WLAN's, even though this is not typical in
hotspot-like activities)
An IX is based on a layer 2 infrastructure that can be, either
local to given building, or distributed over a large are by the
way multiple interconnected point of presence. This layer 2
==> note that there are also Layer-3 exchanges (the same applies to IPv4
-- there is zero differences there)
==> another issue to describe is how, in a L2 model, connections are
established: ie, one big L2 mesh, or e.g. point-to-point L2 (e.g. through
peer-to-peer VLAN's or ATM PVC's).
==> an issue to note is that in some L2 systems, multicast and/or IPv6 are
separated in different VLAN's and PVC's. (This has some advantageous
consequences.)
10.1.1 Hardware
Basically, a regular IX is based on a layer 2 switch, or set of
layer 2 switches that may either local to a building, or
distributed over larger area. It provides also room space and
power supply to enable long haul providers to install their own
routers and to exchange routes to each other according to a
peering agreement.
==> the last sentence is not correct: IX's are in no way forced to provide
any room space or supply for routers. In many cases, they don't.
Providers connect to the IX using a circuit, which is hooked up to the L2
fabric.
Semi/Editorial:
---------------
The local border routers are
route reflector clients of the core.
==> add "often" or "sometimes" here, this is by far not always the case
In some cases CPE equipment is provided by the
CORE ISP.
==> irrelevant in the context of core/backbone networks.
Customer routes are pinned up on core routers.
==> I'm not sure what you're trying to say; please use a bit more formal
language, same under Aggregation and elsewhere.
5.3.2 CMTS Layer-2 Bridge
IPv6 is then deployed on the ISP router infrastructure natively
or using an automatic tunneling scheme like 6to4[RFC3056].
==> move this kind of text to the solutions document.
In an ideal world every IPv4 NAT router would be upgraded to
additionally become a native IPv6 router using 6to4 automatic
tunneling.
In general 6to4 residential gateway devices must be made as
self-configuring as existing IPv4 NAT routers.
==> likewise.
If the CMTS is a
native IPv6 router then it will likely need to participate in
ISPs the IGP of choice. If the CMTS is a bridge, the
infrastructure router(s) that it connects to will need to speak
an IGP. If 6to4[RFC3056] is used, it is recommended that the ISP
sink (and forward) traffic to the anycast 6to4 relay router address
[RFC3068].
==> such as above, talk more of _IPv4_ scenarios!
Existing IPv4 filter
software will not block IPv6 communication. If IPv6 is tunneled
over an IPv4 infrastructure filters may need to examine the
contents of encapsulated packets.
==> likewise.
5.8 Host Gear
Dual stack DNS server is necessary if you want to support
IPv6-only CPE equipment.
DDNS is pretty much mandatory if you want to give CPE devices DNS
names. This is because only the IPv6 host knows what its full
IPv6 address is (esp when privacy addresses are used).
Transition functionality.. which? where?
v4/v6 translation between devices in the home is done where? If
RFC1918 addresses are in use (perhaps behind the NAT), then there
isn't much choice but to do it inside the CPE box.
Transparent proxy caches aren't going to cache IPv6 web traffic.
==> talk about v4, not about v6. Almost all of this should go to the
solutions doc.
Customer Premises | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +-----+ +-----+
|Hosts|--| DSL +-------+DSLAM|
+-----+ |Modem| | +----+
+-----+ +-----+ |
|
+-----+ +------+ | +-----+ +-------+
|Hosts|--|Router| +--+ BAS +----+ ISP | ISP
+-----+ +--+---+ +--+ | | Edge +===> Network
| | +-----+ | Router|
+--+--+ | +-------+
| DSL +---+ |
|Modem| | |
+-----+ | |
| +-----+ |
+-----+ +------+ +---+DSLAM+----+
|Hosts|--|Router| +---+ |
+-----+ +--+---+ | +-----+
| |
+--+--+ |
| DSL +---+
|Modem|
+-----+
==> I'd replace the last one with the scenario where a host is directly
attached to the DSLAM, through a DSL PCI/ISA card. This changes certain
assumptions slightly.
(Broadband Access Server = DSLAM aggregator), which is in charge
of directing them to the POP (Point Of Presence = the ISP Edge
==> I'd rather see that the term "POP" (here and later) would not be used
in this context. We're mixing layers here. PoP is a layer 1 term
(physical location and place of the connection, where the eqipment is),
not layer 2 or 3.
Figure 6.2.2.2
==> this figure is identical to 6.2.2.1, we can very well live with just
one of them, thanks -- same in other a few other figures :-)
addresses today. Customers are usually disconnected every day
==> "often" or "sometimes" rather than "usually"
IRR
routing policy is generally registered by the ISP or NSP but in
some cases the dialup provider may register policy.
==> it's not probably obvious to all readers what you mean so that should
be expanded a bit.
9.3 Routing
IGP
The interior routing for Ethernet access doesn't differ to any
other routing used with in one particular ISP.
The routing protocols normally used are IS-IS or OSPF.
EGP
BGP is used for exchanging external routes.
Exterior routing is not used towards the end customers since the
customer networks are seen as being directly connected to the
edge router and not having a CPE router in between. This means
that the customer network is routed directly to an interface on
the edge router and not to a customer router.
==> under broadband ethernet, a shorter explanation why IGP/EGP does not
apply would probably be just as good.
An IPv6 IX, unlike current NAPs, may assign independent long-haul
provider addresses, according to [RFC2374]. An organization
subscribing such addresses will be able to change long-haul
provider without having to renumber.
==> solutions category (note that this text is mostly outdated anyway, as
2374 is getting historic)
According to [RFC2374] aggreatable addresses are organized into a
three level hierarchy. IXs, together with long haul providers,
belong the higher one called "Public Topology". IXs will allocate
IPv6 addresses to its directly connected subscribers, providing
them addressing independence from long haul providers. IX will
then have to include layer 3 functions, e.g. by the means of a
router, in order to exchange routes with long haul provider, for
gaining global connectivity to its subscribers. The figure below,
describes such a new type of IX introducing layer 3 functions,
and that topology differs from regular IPv4 IX.
==> ditto (some bits could maybe be left here)
==> figure 10.1b can probably also go.
In the case of an IX providing independent addresses to its
directly connected subscribers, the needed layer 3 function will
be based on a regular IPv6 router.
==> same here.
REFERENCES
[01] TR-025 Core Network Architecture for Access to Legacy Data
Networks over ADSL, TR-025 - ADSL Forum, September 1999
[02] RFC 1661 The Point-to-Point Protocol (PPP)
==> split the references and add them in the proper format.
Editorial:
----------
This section describes the general topologies of and
characteristics of today's CORE networks. Although there are
==> s/topologies of/topologies/
aggregation of long haul circuits to remote sites. The
==> s/haul /haul /
Loopback interfaces and point-to-point links are what make up
routes within the IGP.
==> s/are what make up routes/make up the routes/
peers. In the case of customer connections, there are peer
groups that are configured to send FULL_ROUTES, CUSTOMER-ROUTES
or DEFAULT-ROUTES to a particular set of customers. To perform
==> any particular reason to put these in uppercase?
routed connection. Cacheing infrastructure is deployed in CORE
==> s/Cacheing/Caching/
router. It is usually connected between the cable modem and all
other CPE equipment allows multiple devices to share a single
==> s/allows/allowing/
configuration overhead. The NAT/DHCP router is a directional
IPv4-only device in the communication path between the CMTS and
the CPE.
==> "directional" ? I can only try to guess what you mean, reword.
CPE NAT boxes are rectifying routers. This can be viewed as an
implementation of an "outgoing only" security policy.
==> likewise with "rectifying".
ToD [RFC0868] for initial time synchronization.
==> "ToD" is an unknown abbreviation for me, don't use it.
Various MIBs for RF and CPE filter configuration.. DOCSIS OSSI
==> same for "RF".
6. Broadband DSL Networks
This section describes the infrastructure that exists in todays
High Speed DSL Networks.
==> s/todays/today's/
The hosts are connected to the DSL network either directly
through a modem, either through a router and a modem.
==> reword at least the second line, I'm having trouble parsing it.
opened to each NSP, but several PVCs are sometimes used when the
NSP offers differentiated services (QoS...).
==> reword the last line to better integrate QoS if a referral to it is
necessary.
results in a decrease of the MSS of TCP that applications should
==> MSS needs to be spelled out.
6.2.3 L2TP ACCESS AGGREGATION (LAA) MODEL
==> all the headings need to be in a proper format, in this case:
L2TP Access Aggregation (LAA) Model
presence, via a L2TP tunnel. When a CPE initiates a session with
==> is it "an L2TP" or "a L2TP"? Typically if you pronounce that, you'd
say "an el-two-tee-pee", but I guess putting "a" as for the written form
would also be ok.
and are given a new address each time they reconnect. Most of
the times,
==> s/times/time/
majority of internet users use today to get online. The
scenarios will include solutions where the dial infrastructure is
controlled by one entity as well as solutions where ISPs lease
modems from a wholesale modem providers.
==> s/a wholesale/wholesale/, or some other rewording.
made the user credentials are sent to the Authentication server.
==> s/A/a/
(IEEE 802.11) and 11 Mbps (IEEE 802.11b) to 54 Mbps
(IEEE 802.11a).
==> a lot of other stds also give (theoretical) 54 Mbps as you know --
perhaps change: s/IEEE 801.11a/IEEE 801.11a and others/.
mechanisms are presented in 3.x.5 in detail. Once the host is
authenticated, AP acts as a bridge in order to relay host's
information to ISP or vice versa. Various access network
technologies can be used between AP and ISP. Lease line, xDSL
==> 3.x.5 ??
==> s/Lease/Leased/
ISPs supply not static addresses by default but
dynamic addresses by DHCP.
==> reword this completely.
they reconnect. Most of the times, customers use private
==> s/times/time/
ISPs may need to configure traffic filtering or provisioning on
demand of their customers.
==> reword
Like ethernet, IEEE 802.11 standard dose not define
authentication and security mechanisms.
==> s/eth/Eth/
==> s/dose/does/
Moreover, WLAN is
basically a broadcast network and each host can listen
information of another host within the same AP service area.
==> reword the last two lines, especially "listen information of another
host"..
This mechanism supports host that does not support IEEE 802.1x.
==> s/host that does/hosts that do/
Therefore, very complicated data privacy mechanism must
be provided in order not to be revealed by other hosts except
intended host.
==> reword from "releveled..."
9.1. Topology
Physical
The layouts of Ethernet based accesses to the home are all almost
identical. They usually consist in a star topology terminated in
==> different formatting with subtitles, please.
==> s/consist in/consist of/
some cases used. It can consist of web login or PPPoE. Web login
can be done in two ways, one time login where the device's MAC-
address is registered and kept or session login where login is
==> s/one time/as one time/
==> s/session login/as session login/
local to given building, or distributed over a large are by the
way multiple interconnected point of presence. This layer 2
infrastructure enables players (e.g. long haul providers)
==> s/are by the way/area in/
==> s/presence/precences/
==> use a more formal&better term than "player". :-)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings