Internet Engineering Task Force Ken Carlberg
INTERNET DRAFT G11
Feb 4, 2005
A Framework for Supporting Emergency Telecommunications
Services (ETS) Within a Single Administrative Domain
<draft-ietf-ieprep-domain-frame-04.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document presents a framework discussing the role of various
protocols and mechanisms that could be considered candidates for
supporting Emergency Telecommunication Services (ETS) within a single
administrative domain. Comments about their potential usage as well
as their current deployment are provided to the reader. Specific
solutions are not presented.
1. Introduction
This document presents a framework for supporting Emergency Telecom-
munications Services (ETS) within the scope of a single
Carlberg Expires Aug 4, 2005 [Page 1]
Internet Draft ETS Single Domain Framework Feb 4, 2005
administrative domain. This narrow scope provides a reference point
for considering protocols that could be deployed to support ETS.
[REQ] is a complimentary effort that articulates requirements for a
single administrative domain. We use this other effort as both a
starting point and guide for this document.
A different example of a framework document for ETS is [FRAME], which
focused on support for ETS within IP telephony. In this case, the
focal point was a particular application whose flows could span mul-
tiple autonomous domains. Even though this document uses a somewhat
more constrained perspective than [FRAME], we can still expect some
measure of overlap in the areas that are discussed.
1.1. Differences between Single and Inter-domain
The progression of our work in the following sections is helped by
stating some key differences between the single and inter-domain
cases. From a general perspective, one can start by observing the
following:
a) Congruent with physical topology of resources, each domain
is an authority zone and there is currently no scalable way
to transfer authority between zones.
b) Each authority zone is under separate management
c) Authority zones are run by competitors, which acts as
further deterrent to transferring authority.
As a result of the initial statements in (a) through (c) above, addi-
tional observations can be made that distinguish the single and
inter-domain case, as stated in the following"
d) Different policies might be implemented in different
administrative domains.
e) There is an absence of any practical method for ingress nodes of
a transit domain to authenticate all of the IP network layer
packets that have labels indicating a preference or importance.
f) Given item (d) above, all current inter-domain QoS mechanisms
at the network level generally create easily exploited and
significantly painful DoS/DDoS attack vectors on the network.
g) A single administrative domain can deploy various mechanisms
(e.g. Access Control Lists) into each and every edge device
(e.g. ethernet switch or router) to ensure that only
authorized end-users (or layer 2 interfaces) are able to emit
frames/packets with non-default QoS labels into the network.
Carlberg Expires Aug 4, 2005 [Page 2]
Internet Draft ETS Single Domain Framework Feb 4, 2005
This is not feasible in the inter-domain case because the
inter-domain link contains aggregated flows. In addition, the
dissemination of Access Control Lists at the network level is
not scalable in the inter-domain case.
h) A single domain can deploy mechanisms into the edge devices to
enforce its domain-wide policies -- without having to trust any
3rd party to configure things correctly. This is not possible
in the inter-domain case.
While the above is not an all-inclusive set of differences, it does
provide some rationale why one may wish to focus efforts in the more
constrained scenario of a single administrative domain.
2. Common Practice: Provisioning
The IEPREP working group, and mailing list, has had extensive discus-
sions about over-provisioning. Many of these exchanges have debated
the need for QoS mechanisms versus over-provisioning of links.
In reality, most IP network links are provisioned with a percentage
of excess capacity beyond that of the average load. The 'shared'
resource model together with TCP's congestion avoidance algorithms
helps compensate for those cases where spikes or bursts of traffic
are experienced by the network.
The thrust of the debate within the IEPREP working group is whether
it is always better to over provision links to such a degree that
spikes in load can still be supported with no loss due to congestion.
Advocates of this position point to many ISPs in the U.S. that take
this approach instead of using QoS mechanisms to honor agreements
with their peers or customers. These advocates point to cost effec-
tiveness in comparison to complexity and security issues associated
with other approaches.
Proponents of QoS mechanisms argue that the relatively low cost of
bandwidth enjoyed in the US (particularly, by large ISPs) is not
necessarily available throughout the world. Beyond cost the subject
of cost, some domains are comprised of physical networks that support
wide disparity in bandwidth capacity -- e.g., attachment points con-
nected to high capacity fiber and lower capacity wireless links.
This document does not advocate one of these positions over the
other. The author does advocate that network
administrators/operators should perform a cost analysis between over
provisioning for spikes versus QoS mechanisms as applied within a
domain and its access link to another domain (e.g., a customer and
Carlberg Expires Aug 4, 2005 [Page 3]
Internet Draft ETS Single Domain Framework Feb 4, 2005
its ISP). This analysis, in addition to examining policies and
requirements of the administrative domain, should be the key to
deciding how (or if) ETS should be supported within the domain.
If the decision is to rely on over provisioning, then some of the
following sections will have little to no bearing on how ETS is sup-
ported within a domain. The exception would be labeling mechanisms
used to convey information to other communication architectures
(e.g., SIP-to-SS7/ISUP gateways).
3. Objective
The primary objective is to provide a target measure of service
within a domain for flows that have been labeled for ETS. This level
may be better than best effort, the best available service that the
network (or parts thereof) can offer, or a specific percentage of
resource set aside for ETS. [REQ] presents a set of requirements in
trying to achieve this objective.
This framework document uses [REQ] as a reference point in discussing
existing areas of engineering work or protocols that can play a role
in supporting ETS within a domain. Discussion of these areas and
protocols are not to be confused with expectations that they exist
within a given domain. Rather, the subjects discussed in Section 4
below are ones that are recognized as candidates that can exist and
could be used to facilitate ETS users or data flows.
3.1. Scenarios
One of the topics of discussion that arises on the IEPREP mailing
list, and the working group meetings, is the operating environment of
the ETS user. Many variations can be dreamed of with respect to
underlying network technologies and applications. Instead of getting
lost in hundreds of potential scenarios, we attempt to abstract the
limit the scenarios into two simple case examples.
(a) A user in their home network attempts to use or leverage any
ETS capability within the domain.
(b) A user visits a foreign network and attempts to use or
leverage any ETS capability within the domain.
We borrow the terms "home" and "foreign" network from that used in
Mobile IP [rfc3344]. Case (a) is considered the normal and vastly
most prevalent scenario in today's Internet. Case (b) above may
Carlberg Expires Aug 4, 2005 [Page 4]
Internet Draft ETS Single Domain Framework Feb 4, 2005
simply be supported by the Dynamic Host Configuration Protocol (DHCP)
[rfc2131], or a static set of addresses, that are assigned to 'visi-
tors' of the network. This effort is predominantly operational in
nature and heavily reliant on the management and security policies of
that network.
A more ambitious way of supporting the mobile user is through the use
of the Mobile IP (MIP) protocol. In this case and at the IP level,
foreign networks introduce the concept of triangle routing and the
potential for multiple access points and service context within a
subnetwork. In addition, policy plays a critical role in dictating
the measure of available services to the mobile user.
The beaconing capability of MIP allows it to offer a measure of
application transparent mobility as a mobile host (MH) moves from one
subnetwork to another. However, this feature may not be available in
most domains. In addition, its management requirements may
discourage its widespread deployment and use. Hence, users should
probably not rely on its existence, but rather may want to expect a
more simpler approach based on DHCP as described above. The subject
of mobile IP is discussed below in Section 4.
4. Topic Areas
The topic areas presented below are not presented in any particular
order or along any specific layering model. They represent capabili-
ties that may be found within an administrative domain. Many are
topics of on-going work within the IETF.
It must be stressed that readers of this document should not expect
any of the following to exist within a for ETS users. In many cases,
while some of the following areas have been standardized and in wide
use for several years, others have seen very limited deployment.
4.1. MPLS
Multi-Protocol Label Switching (MPLS) is generally the first protocol
that comes to mind when the subject of traffic engineering is brought
up. MPLS is an intra-domain routing protocol that produces Labeled
Switched Paths (LSP) through a network [rfc3031]. When traffic
reaches the ingress boundary of an MPLS domain (which may or may not
be congruent with an administrative domain), the packets are classi-
fied, labeled, scheduled, and forwarded along an LSP.
[rfc3270] is a Request For Comment (RFC) describing how MPLS can be
used beyond its inherent traffic engineering and routing capabilities
Carlberg Expires Aug 4, 2005 [Page 5]
Internet Draft ETS Single Domain Framework Feb 4, 2005
to support Differentiated Services. The RFC discusses the use of the
3 bit EXP (experimental) field to convey the Per Hop Behavior (PHB)
to be applied to the packet. As we shall see in later subsections,
this three bit field can be mapped to fields in several other proto-
cols.
The inherent feature of classification, scheduling, and labeling are
viewed as symbiotic and therefore many times it is integrated with
other protocols and architectures. Examples of this include RSVP and
Differentiated Services. Below, we discuss several instances where a
given protocol specification or mechanism has been known to be com-
plimented with MPLS. This includes the potential labels that may be
associated with ETS. However, we stress that MPLS is only one of
several approaches to support traffic engineering. In addition, the
complexity of the MPLS protocol and architecture may make it suited
for only large domains.
4.2. RSVP
The original design of RSVP, together with the Integrated Services
model, was one of an end-to-end signaling capability to set up a path
of reserved resources that spanned networks and administrative
domains [rfc2205]. Currently, RSVP has not been widely deployed by
network administrators for QoS across domains. Today's limited
deployment by network administrators so far has been mostly con-
strained to boundaries within a domain, and commonly in conjunction
with MPLS signaling. Early deployments of RSVP ran into unantici-
pated scaling issues; it is not entirely clear how scalable an RSVP
approach would be across the Internet.
[rfc3209] is one example of how RSVP has evolved to compliment
efforts that are scoped to operate within a domain. In this case,
extensions to RSVP are defined that allow it to establish intra-
domain Labeled Switched Paths (LSP) in Multi-Protocol Labeled Switch-
ing (MPLS).
[rfc2750] specifies extensions to RSVP so that it can support generic
policy based admission control. This standard goes beyond the sup-
port of the POLICY_DATA object stipulated in [rfc3209], by defining
the means of control and enforcement of access and usage policies.
While the standard does not advocate a particular policy architec-
ture, the IETF has defined one that can compliment [rfc2750] -- we
expand on this in subsection 4.3 below.
Carlberg Expires Aug 4, 2005 [Page 6]
Internet Draft ETS Single Domain Framework Feb 4, 2005
4.2.1. Relation to ETS
The ability to reserve resources correlates to an ability to provide
preferential service for specifically classified traffic -- the clas-
sification being a tuple of 1 or more fields which may or may not
include an ETS specific label. In cases where a tuple includes a
label that has been defined for ETS usage, the reservation helps
ensure that an emergency related flow will be forwarded towards its
destination. Within the scope of this document, this means that RSVP
would be used to facilitate the forwarding of traffic within a
domain.
We note that this places an importance on defining a label and an
associated field that can be set and/or examined by RSVP capable
nodes.
Another important observation is that major vendor routers currently
constrain their examination of fields for classification to the net-
work and transport layers. This means that application layer labels
will mostly likely be ignored by routers/switches.
4.3. Policy
The Common Open Policy Service (COPS) protocol [rfc2748] was defined
to provide policy control over QoS signaling protocols, such as RSVP.
COPS is based on a query/response model in which Policy Enforcement
Points (PEPs) interact with Policy Decision Points (i.e., policy
servers) to exchange policy information. COPs provides application
level security and can operate over IPSEC or TLS. COPS is also
stateful protocol that also supports a push model. This means that
servers can download new policies, or alter existing ones to known
clients.
[rfc2749] articulates the usage of COPS with RSVP. This document
specifies COPS client types, context objects, and decision objects.
Thus, when an RSVP reservation is received by a PEP, the PEP decides
whether to accept or reject it based on policy. This policy informa-
tion can be stored a priori to the reception of the RSVP PATH mes-
sage, or it can be retrieved in an on-demand basis. A similar course
of action could be applied in cases where ETS labeled control flows
are received by the PEP. This of course would require an associated
(and new) set of documents that first articulates types of ETS sig-
naling and then specifies its usage with COPS.
A complimentary document to the COPS protocols is [rfc3084], which
describes the use of COPS for policy provisioning.
Carlberg Expires Aug 4, 2005 [Page 7]
Internet Draft ETS Single Domain Framework Feb 4, 2005
As a side note, the current lack in deployment by network administra-
tors of RSVP has also played at least an indirect role in the subse-
quent lack of implementation & deployment of COPS. [rfc3535] is an
output from the IAB Network Management Workshop in which the topic of
COPS and its current state of deployment was discussed. At the time
of that workshop in 2002, COPS was considered a
technology/architecture that did not fully meet the needs of network
operators. It should also be noted that at the 60'th IETF meeting
held in San Diego in 2004, COPS was discussed as a candidate protocol
that should be declared as historic because of its lack of use and
concerns about its design. In the future, an altered design of COPS
may emerge that addresses the concern of operators, but speculation
of that or other possibilities is beyond the scope of this document.
4.4. Subnetwork Technologies
This is a generalization of work that is considered "under" IP and
for the most part outside of the IETF standards body. We discuss
some specific topics here because there is a relationship between
them and IP in the sense that each physical network interacts at its
edge with IP.
4.4.1. 802.1
The IEEE 802.1q standard defined a tag appended to a Media Access
Controller (MAC) frame for support of layer 2 Virtual Local Area Net-
works (VLAN). This tag has two parts: a VLAN identifier (12 bits)
and a Prioritization field of three bits. A subsequent standard,
IEEE 802.1p, later incorporated into a revision of IEEE 802.1d,
defined the Prioritization field of this new tag [iso15802]. It con-
sists of eight levels of priority, with the highest priority being a
value of 7. Vendors may choose a queue per priority codepoint, or
aggregate several codepoints to a single queue.
The three bit Prioritization field can be easily mapped to the old
ToS field of the upper layer IP header. In turn, these bits can also
be mapped to a subset of differentiated code points. Bits in the IP
header that could be used to support ETS (e.g., specific Diff-Serv
code points) can in turn be mapped to the Prioritization bits of
802.1p. This mapping could be accomplished in a one-to-one manner
between the 802.1p field and the IP ToS bits, or in an aggregate
manner if one considers the entire Diff-Serv field in the IP header.
In either case, because of the scarcity of bits, ETS users should
expect that their traffic will be combined or aggregated with the
same level of priority as some other types of "important" traffic.
In other words, given the existing 3 bit Priority Field for 802.1p,
Carlberg Expires Aug 4, 2005 [Page 8]
Internet Draft ETS Single Domain Framework Feb 4, 2005
there will not be an exclusive bit value reserved for ETS traffic.
Certain vendors are currently providing mappings between 802.1p field
and the ToS bits. This is in addition to integrating the signaling
of RSVP with the low level inband signaling offered in the Priority
field of 802.1p.
It is important to note that the 802.1p standard does not specify the
correlation of a layer 2 codepoint to a physical network bandwidth
reservation. Instead, this standard provides what has been termed as
"best effort QoS". The value of the 802.1p Priority code points is
realized at the edges: either as the MAC payload is passed to upper
layers (like IP), or bridged to other physical networks like Frame
Relay. Either of these actions help provide an intra-domain wide
propagation of a labeled flow for both layer 2 and layer 3 flows.
4.4.2. Cable Networks
The Data Over Cable Service Interface Specification (DOCSIS) is a
standard used to facilitate the communication and interaction of the
cable subnetwork with upper layer IP networks [docsis]. Cable sub-
networks tend to be asynchronous in terms of data load capacity:
typically, 27M downstream, and anywhere from 320kb to 10M upstream
(i.e., in the direction of the user towards the Internet).
The evolution of the DOCSIS specification, from 1.0 to 1.1, brought
about changes to support a service other than best effort. One of
the changes was indirectly added when the 802.1D protocol added the
Priority field, which was incorporated within the DOCSIS 1.1 specifi-
cation. Another change was the ability to perform packet fragmenta-
tion of large packets so that Priority marked packets (i.e., packets
marked with non-best effort labels) can be multiplexed in between the
fragmented larger packet.
Its important to note that the DOCSIS specifications do not specify
how vendors implement classification, policing, and scheduling of
traffic. Hence, operators must rely on mechanisms in Cable Modem
Termination Systems (CMTS) and edge routers to leverage indirectly or
directly the added specifications of DOCSIS 1.1. As in the case of
802.1p, ETS labeled traffic would most likely be aggregated with
other types of traffic, which implies that an exclusive bit (or set
of bits) will not be reserved for ETS users. Policies and other
managed configurations will determine the form of the service experi-
enced by ETS labeled traffic.
Traffic engineering and management of ETS labeled flows, including
its classification and scheduling at the edges of the DOCSIS cloud,
Carlberg Expires Aug 4, 2005 [Page 9]
Internet Draft ETS Single Domain Framework Feb 4, 2005
could be accomplished in several ways. A simple schema could be
based on non-FIFO queuing mechanisms like class based queuing,
weighted fair queuing (or combinations and derivations thereof). The
addition of active queue management like Random Early Detection could
provide simple mechanisms for dealing with bursty traffic contribut-
ing to congestion. A more elaborate scheme for traffic engineering
would include the use of MPLS. However, the complexity of MPLS
should be taken into consideration before its deployment in networks.
4.5. Multicast
Network layer multicast has existed for quite a few years. Efforts
such as the Mbone have provided a form of tunneled multicast that
spans domains, but the routing hierarchy of the Mbone can be con-
sidered flat and non-congruent with unicast routing. Efforts like
the Multicast Source Discovery Protocol [rfc3618] together with the
Protocol Independent Multicast Sparse Mode (PIM-SM) have been used by
a small subset of Internet Service Providers to provide form of
inter-domain multicast [rfc2362]. However, network layer multicast
has for the most part not been accepted as a common production level
service by a vast majority of ISPs.
In contrast, intra-domain multicast in domains has gained more accep-
tance as an additional network service. Multicast can produce denial
of service attacks using the any sender model, with the problem made
more acute with flood & prune algorithms. Source specific multicast
[ssm], together with access control lists of who is allowed to be a
sender, reduces the potential and scope of such attacks.
4.5.1. IP Layer
The value of IP multicast is its efficient use of resources in send-
ing the same datagram to multiple receivers. An extensive discussion
on the strengths and concerns about multicast is outside the scope of
this document. However, one can argue that multicast can very natur-
ally compliment the push-to-talk feature of land mobile radio net-
works (LMR).
Push-to-talk is a form of group communication where every user in the
"talk group" can participate in the same conversation. LMR is the
type of network used by First Responders (e.g., police, fireman, and
medical personnel) that are involved in emergencies. Currently, cer-
tain vendors and providers are offering push-to-talk service to the
general public in addition to First Responders. Some of these sys-
tems are operated over IP networks, or are interfaced with IP net-
works to extend the set of users that can communicate with each
Carlberg Expires Aug 4, 2005 [Page 10]
Internet Draft ETS Single Domain Framework Feb 4, 2005
other. We can consider at least a subset of these systems as either
closed IP networks, or domains, since they do not act as transits to
other parts of the Internet.
The potential integration of LMR talk groups with IP multicast is an
open issue. LMR talk groups are established in a static manner with
man-in-the-loop participation in their establishment and teardown.
The seamless integration of these talk groups with multicast group
addresses is a feature that has not been discussed in open forums.
4.5.2. 802.1d
The IEEE 802.1d standard specifies fields and capabilities for a
number of features. In subsection 4.3.2 above, we discussed its use
for defining a Prioritization field. The 802.1d standard also covers
the topic of filtering MAC layer multicast frames.
One of the concerns about multicast are broadcast storms that can
arise and generate a denial of service against other users/nodes.
Some administrators purposely filter out multicast frames in cases
where the subnetwork resource is relatively small (e.g., 802.11 net-
works). Operational considerations with respect to ETS may wish to
consider doing this in an as-needed basis based on the conditions of
the network against the perceived need for multicast. In cases where
filtering out multicast can be activated dynamically, COPS may be a
good means of providing consistent domain-wide policy control.
4.6. Discovery
If a service is being offered to explicitly support ETS, then it
would seem reasonable that discovery of the service may be of bene-
fit. For example, if a domain has a subset of servers that recognize
ETS labeled traffic, then dynamic discovery of where these servers
are (or even if they exist) would be more beneficial compared to
relying on statically configured information.
The Service Location Protocol (SLP) [rfc2608] is designed to provide
information about the existence, location, and configuration of
networked services. In many cases, the name of the host supporting
the desired service is needed to be known a priori in order for users
to access it. SLP eliminates this requirement by using a descriptive
model that identifies the service. Based on this description, SLP
then resolves the network address of the service and returns this
information to the requester. An interesting design element of SLP
is that it assumes that the protocol is run over a collection of
nodes that are under the control of a single administrative
Carlberg Expires Aug 4, 2005 [Page 11]
Internet Draft ETS Single Domain Framework Feb 4, 2005
authority. This model follows the scope of this framework document.
However, the scope of SLP may be better suited for parts of an enter-
prise network versus an entire domain.
Anycasting [rfc1546] is another means of discovering nodes that sup-
port a given service. Interdomain anycast addresses, propagated by
BGP, have been used by multiple root servers for a while. [rfc3513]
covers the topic of anycast addresses for IPv6. Unlike SLP,
users/applications must know the anycast address associated with the
target service. In addition, responses to multiple requests to the
anycast address may come from different servers. Hence, applicabil-
ity of anycast may be narrow in scope. Detailed tradeoffs between
this approach and SLP is outside the scope of this framework docu-
ment.
4.7. Mobility
The mobile user extends the scenario of how an ETS user operates
within a domain. While the ownership of the mobile host may be dif-
ferent from other nodes in the same domain, the management of that
node in terms of policies and administration is still defined by the
foreign network (i.e., domain) that it is attached to.
4.7.1. Mobile IP
Currently within the IETF, the subject of mobility is addressed in
several ways. The oldest and most mature area involves mobile hosts
and its support based on the Mobile IP protocol [rfc3344]. In this
case, mobility is kept transparent from the upper layers and its sup-
port is focused at the network layer.
The Mobile IP protocol (MIP) and architecture addresses the fundamen-
tal characteristics of a ETS user migrating to a foreign network and
attempting to contact other users. One can also make an argument
that the perceived needs of an ETS user, e.g., labeling traffic to
distinguish it from other flows can also be achieved independent of
the MIP. A potential exception to this position is the "busy" bit
that can be set during the initial registration of the Mobile Host
(MH) to the Foreign Network. If the bit is tied to a maximum number
of simultaneous number of MHs, then it may be of interest to specify
an extension that distinguishes an ETS capable MH from other MHs.
Local policy would determine the course of action to be taken.
Carlberg Expires Aug 4, 2005 [Page 12]
Internet Draft ETS Single Domain Framework Feb 4, 2005
4.7.2. Other Areas of Mobility
As of the publication of this document, there are other working
groups within the IETF that are involved in mobility. The Mobile
Ad-Hoc Networking (MANET) working group has focused on the case in
which all nodes, routers and hosts, can move in relation to each
other. The output of this group has been in the form of experimental
protocols, and so the subject area may be considered too immature in
considering how it and the various protocols can play a role in sup-
porting ETS.
The Network Mobile (NEMO) working group has just recently been formed
to address the issues that arise when entire networks move in rela-
tion to each other. This effort can currently be considered too
immature for supporting ETS.
The Context Transfer, Handoff Candidate Discovery, and Dormant Mode
Host Alerting (SEAMOBY) working group is another relatively new work-
ing group in the area of mobile communications. It too is probably
too immature at this time to be determined if specific aspects could
(or even should) be added to supprt ETS. However, the subject area
of context transfer is an important one and it has the potential to
constructively support ETS.
4.7.3. AAA
Authentication, Authorization, and Accounting (AAA) is an important
subject for mobility since users may access resources from other
domains outside of their own zone of authority. [rfc2977] presents a
set of requirements for AAA and the MIP. When we add the caveat of
the ETS user, we add an additional level of filtering specific sets
of users, which makes the problem of AAA more difficult to support.
In the case of NEMO, SEAMOBY, AAA remains an open issue to be solved.
There are some deployed MANET protocols that have rudimentary AAA
support, but the support is unique to that implementation and not
based on an IETF standard -- which is reasonable since current MANET
protocols are experimental.
4.8. Differentiated Services (Diff-Serv)
There are a number of examples where Diff-Serv [rfc2274] has been
deployed strictly within a domain, with no extension of service to
neighboring domains. Various reasons exist for Diff-Serv not being
widely deployed in an inter-domain context, including ones rooted in
the complexity and problems in supporting the security requirements
Carlberg Expires Aug 4, 2005 [Page 13]
Internet Draft ETS Single Domain Framework Feb 4, 2005
for Diff-Serv code points. An extensive discussion on Diff-Serv
deployment is outside the scope of this document.
[Baker] presents common examples of various codepoints used for well
known applications. The document does not recommend these associa-
tions as being standard or fixed. Rather, the examples in [Baker]
provide a reference point for known deployments that can act as a
guide for other network administrators.
An arguement can be made that Diff-Serv, with its existing code point
specifications of Assured Forwarding (AF) and Expedited Forwarding
(EF), goes beyond what could be needed to support ETS within a
domain. By this we mean that the complexity in terms of maintenance
and support of AF or EF may exceed or cause undue burden on the
management resources of a domain. Given this possibility, users or
network administrators may wish to determine if various queuing
mechanisms, like class based weighted fair queuing, is sufficient to
support ETS flows through a domain. Note, as we stated earlier in
section 2, over provisioning is another option to consider. We
assume that if the reader is considering something like Diff-Serv,
then it has been determined that over provisioning is not a viable
option given their individual needs or capabilities.
5. Security Considerations
Services used to offer better or best available service for a partic-
ular set of users (in the case of this document, ETS users) are prime
targets for security attacks, or simple misuse. Hence, administra-
tors that choose to incorporate additional protocols/services to sup-
port ETS are strongly encouraged to consider new policies to address
the added potential of security attacks. These policies, and any
additional security measures, should be considered independent of any
firewalls that may exist at the edges of the administrative domain.
6. Acknowledgements
Thanks to Ran Atkinson, Scott Bradner, and Kimberly King for comments
and suggestions on this draft.
7. IANA Considerations
This document has no considerations for IANA
Carlberg Expires Aug 4, 2005 [Page 14]
Internet Draft ETS Single Domain Framework Feb 4, 2005
8. References
8.1. Normative Reference
[rfc3668] Bradner, S., "Intellectual Property Rights in IETF
technology", BCP 79, RFC 3668, February 2004
8.2. Informative References
[REQ] Carlberg, K., "Requirements for Supporting Emergency
Telecommunications Services in Single Domains", Internet
Draft, draft-ietf-ieprep-domain-req-01.txt, Work In
Progress, June 2003
[FRAME] Carlberg, K,. et. al, "Framework for Supporting ETS in IP
Telephony", Internet Draft, Work In Progress, June, 2003
[rfc3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002
[rfc2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997
[rfc3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[rfc3270] Le Faucheur, F., et al, "MPLS Support of Differentiated
Services", RFC 3270, May 2002
[rfc2205] Braden, R., et al, "Resource Reservation Protocol (RSVP)
Version 1 Functional Specification", RFC 2205, Sept 1997
[rfc3209] Awduche, D., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001
[rfc2750] Herzog, S., "RSVP Extensions for Policy Control",
RFC 2750, January 2000
[rfc2748] Durham, D., et al, "The COPS (Common Open Policy
Service) Protocol", RFC 2748, January 2000.
[rfc2749] Herzog, S., et al, "COPS Usage for RSVP", RFC 2749,
January 2000
[rfc3084] Chan, K., et al, "COPS Usage for Policy Provisioning
(COPS-PR)", RFC 3084, March 2001
Carlberg Expires Aug 4, 2005 [Page 15]
Internet Draft ETS Single Domain Framework Feb 4, 2005
[rfc3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003
[iso15802] "Information technology - Telecommunications and
information exchange between systems - Local and
metropolitan area networks - Common specifications -
Part 3: Media Access Control (MAC) Bridges: Revision.
This is a revision of ISO/IEC 10038: 1993, 802.1j-1992
and 802.6k-1992. It incorporates P802.11c, P802.1p
and P802.12e." ISO/IEC 15802-3:1998"
[docsis] "Data-Over-Cable Service Interface Specifications: Cable
Modem to Customer Premise Equipment Interface
Specification SP-CMCI-I07-020301", DOCSIS, March 2002,
http://www.cablemodem.com.
[rfc3618] Meyer, D., Fenner, B., "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003
[rfc2362] Estrin, D., et al, "Protocol Independent Multicast-Sparse
Mode (PIM-SM): Protocol Specification", RFC 2362, June
1998
[rfc2608] Guttman, C., et al, "Service Location Protocol, Version
2", RFC 2608, June 1999.
[rfc1546] Partridge, C., et al, "Host Anycasting Service", RFC
1546, November 1993
[rfc3513] Hinden, R., Deering, S., "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003
[rfc2474] Nichols, K., et al, "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
[baker] Baker, F., et. al., "Configuration Guidelines for
DiffServ Service Classes", Internet Draft,
draft-baker-diffserv-basic-classes-03.txt, Work In
Progress, Feb 2004
[ssm] Holbrook, H., B. Cain, "Source-Specific Multicast for IP",
draft-ietf-ssm-arch--06.txt, Internet Draft, Work in
Progress, Sept 2004
Carlberg Expires Aug 4, 2005 [Page 16]
Internet Draft ETS Single Domain Framework Feb 4, 2005
9. Author's Address
Ken Carlberg
G11
123a Versailles Circle
Baltimore, MD
USA
carlberg@g11.org.uk
Carlberg Expires Aug 4, 2005 [Page 17]
Internet Draft ETS Single Domain Framework Feb 4, 2005
Table of Contents
1. Introduction ................................................... 1
1.1 Differences between Single and Inter-domain .................. 2
2. Common Practice: Provisioning .................................. 3
3. Objective ...................................................... 4
3.1 Scenarios ..................................................... 4
4. Topic Areas .................................................... 5
4.1 MPLS .......................................................... 5
4.2 RSVP .......................................................... 6
4.2.1 Relation to ETS ............................................. 7
4.3 Policy ........................................................ 7
4.4 Subnetwork Technologies ....................................... 8
4.4.1 802.1 ...................................................... 8
4.4.2 Cable Networks ............................................. 9
4.5 Multicast ..................................................... 10
4.5.1 IP Layer ................................................... 10
4.5.2 802.1d ..................................................... 11
4.6 Discovery ..................................................... 11
4.7 Mobility ...................................................... 12
4.7.1 Mobile IP ................................................... 12
4.7.2 Other Areas of Mobility ..................................... 13
4.7.3 AAA ......................................................... 13
4.8 Differentiated Services (Diff-Serv) ........................... 13
5. Security Considerations ....................................... 14
6. Acknowledgements ............................................... 14
7. IANA Considerations ............................................ 14
8. References ..................................................... 15
8.1 Normative Reference ........................................... 15
8.2 Informative References ........................................ 15
9. Author's Address .............................................. 17
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Disclamer
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
Carlberg Expires Aug 4, 2005 [Page 18]
Internet Draft ETS Single Domain Framework Feb 4, 2005
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR-
MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Carlberg Expires Aug 4, 2005 [Page 19]
