[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4958

Internet Engineering Task Force                        Ken Carlberg
INTERNET DRAFT                                         G11
June 9, 2004



                    A Framework for Supporting ETS
                 Within a Single Administrative Domain
                <draft-ietf-ieprep-domain-frame-01.txt>



Status of this Memo
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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.

   For potential updates to the above required-text see:
   http://www.ietf.org/ietf/1id-guidelines.txt

Abstract

   This document presents a framework discussing the role of various
   protocols and mechanisms that could be considered candidates for
   supporting 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
   Telecommunications Service (ETS) within the scope of a single
   administrative domain.  This narrow scope provides a reference point
   for considering protocols that could be deployed to support ETS.  [2]
   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 [3], which



Carlberg                    Expires December 9, 2004            [Page 1]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   focused on support for ETS within IP telephony.  In this case, the
   focal point was a particular application whose flows could span
   multiple autonomous domains.  Even though this document uses a
   somewhat more constrained perspective than [3], 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, which are articulated in the following:

    a) Different policies might be implemented in different
       administrative domains.

    b) There is an absence of any practical method for authenticating
       all of the network layer packets that have labels indicating a
       preference or importance at ingress nodes to other
       administrative domains (e.g. on the uplink into an ISP).

    c) Given item (b) 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.

    d) 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.
       This is not feasable 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.

    e) 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 extentive
   discussions about over-provisioning.  Many of these exchanges have
   debated the need for QoS mechanisms versus over-provisioning of



Carlberg                    Expires December 9, 2004            [Page 2]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   links.

   In reality, nearly all IP network links are over-provisioned with
   excess capacity for 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
   links should be over provisioned 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 effectiveness in
   comparison to complexity and security issues associated with other
   approaches.  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.  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 stub 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
   supported within a stub 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 stub domain for flows that have been labeled for ETS. This
   level may be better than best effort, or it may be the best available
   service that the network (or parts thereof) can offer.  [2] presents
   a set of requirements in trying to achieve this objective.

   This framework document uses [2] 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




Carlberg                    Expires December 9, 2004            [Page 3]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   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 the HOME network attempts to use or leverage any
         ETS capability within the stub domain.

     (b) A user visits a FOREIGN network and attempts to use or
         leverage any ETS capability within the stub domain.

   We borrow the terms "home" and "foreign" network from that used in
   Mobile IP [4].  Case (a) is considered the normal and vastly most
   prevalent scenario in today's Internet.  Case (b) above may simply be
   supported by the Dynamic Host Configuration Protocol (DHCP) [5], or a
   static set of addresses, that are assigned to 'visitors' of the
   network.  This effort is predominantly operational in nature and
   heavily reliant on the management and security policies of that stub
   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 criticial 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 existance, 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
   capabilities 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 for several



Carlberg                    Expires December 9, 2004            [Page 4]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   years, many 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 [6].  When traffic reaches the
   ingress boundary of an MPLS domain (which may or may not be congruent
   with an administrative domain), the packets are classified, labeled,
   scheduled, and forwarded along an LSP.

   [7] is an RFC describing how MPLS can 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 protocols.

   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
   complimented 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 capability that spanned networks and
   administrative domains [8].  Currently, RSVP has not been widely
   deployed, and the limited deployment so far has been mostly
   constrained to boundaries within a domain.  Early deployments of RSVP
   ran into unanticipated scaling issues; it is not entirely clear how
   scalable an RSVP approach would be across the Internet.  Also,
   currently many network products do not support RSVP for anything
   beyond simple MPLS signalling.

   [9] is one example of how RSVP has evolved to compliment efforts that
   are scoped to operate within a domain.  In this case, extentions to
   RSVP are defined that allow it to establish intra-domain Labled
   Switched Paths (LSP) in Multi-Protocol Labeled Switching (MPLS).

   [10] specifies extentions to RSVP so that it can support generic
   policy based admission control.  This standard goes beyond the



Carlberg                    Expires December 9, 2004            [Page 5]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   support of the POLICY_DATA object stipulated in [9], by defining the
   means of control and enforcement of access and usage policies.  While
   the standard does not advocate a particular policy architecture, the
   IETF has defined one that can compliment [10] -- we expand on this in
   subsection 4.3 below.

4.2.1 Relation to ETS

   The ability to reserve resources correlates to an ability to provide
   preferential service for specifically classified traffic -- the
   classification being a tuple of 1 or more fields.  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 stub 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
   network and transport layers.  This means that application layer
   labels will mostly likely be ignored by routers/switches.  Thus,
   endpoints (which may be a server or proxy) that intend to add RSVP
   support for ETS should map application layer ETS labels to labels at
   the network or transport layer.

4.3 Policy

   The Common Open Policy Service (COPS) protocol [11] 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.

   [12] 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
   information can be stored a priori to the reception of the RSVP PATH
   message, or it can be retrieved in an on-demand basis.  A similar
   course of action could be applied in cases where ETS labeled control



Carlberg                    Expires December 9, 2004            [Page 6]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   flows are received by the PEP.  This of course would require an
   associated (and new) set of documents that first articulates types of
   ETS signaling and then specifies its usage with COPS.

   A complimentary document to the COPS protocols is [13], which
   describes the use of COPS for policy provisioning.

   As a side note, the current lack in deployment of RSVP in network
   products has also played at least an indirect role in the subsequent
   lack of implementations & deployment of COPS.  [14] is an additional
   source for recent thoughts on this subject.

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
   Networks (VLAN).  This tag has two parts: a VLAN identifier (12 bits)
   and a Prioritiation 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 [15].  It consists 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,
   there will not be an exclusive bit 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



Carlberg                    Expires December 9, 2004            [Page 7]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   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 [16].  Cable
   subnetworks 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
   specification.  Another change was the ability to perform packet
   fragmentation of large packets so that Priority marked packets (i.e.,
   packets marked with non-best effort labels) can be multiplexed
   inbetween 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
   experienced by ETS labeled traffic.

   Traffic engineering and management of ETS labeled flows, including
   its classification and scheduling at the edges of the DOCSIS cloud,
   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



Carlberg                    Expires December 9, 2004            [Page 8]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   contributing 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
   considered flat and non-congruent with unicast routing.  Efforts like
   the Multicast Source Discovery Protocol [17] 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 [18].  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 stub domains has gained more
   acceptance as an additional network service.  This support is further
   enhanced by corresponding support by physical networks.

4.5.1  IP Layer

   The value of IP multicast is its efficient use of resources in
   sending 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 naturally compliment the push-to-talk feature of land mobile
   radio networks (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,
   certain vendors and providers are offering push-to-talk service to
   the general public in addition to First Responders.  Some of these
   systems are operated over IP networks, or are interfaced with IP
   networks to extend the set of users that can communicate with each
   other.  We can consider at least a subset of these systems as either
   closed IP networks, or stub 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 establishement and teardown.
   The seamless integration of these talk groups with multicast group
   addresses is a feature that has not been discussed in open forums.



Carlberg                    Expires December 9, 2004            [Page 9]

Internet Draft        ETS Single Domain Framework           June 9, 2004


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
   networks).  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
   benefit.  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 benefitial compared
   to relying on statically configured information.

   The Service Location Protocol (SLP) [19] is designed to provide
   information about the existance, 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
   authority.  This model follows the scope of this framework document.

   Anycasting [20] is another means of discovering nodes that support a
   given service.  Interdomain anycast addresses, propagated by BGP,
   have been used by one of the root servers for a while.  [21] covers
   the topic of anycast addresses for IPv6.  Unlike SLP,
   users/applications must know the anycast address associated with the
   target service.  The tradeoffs between this approach and SLP is
   outside the scope of this framework document.


4.7 Mobility



Carlberg                    Expires December 9, 2004           [Page 10]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   The mobile user extends the scenario of how an ETS user operates
   within a domain.  While the ownership of the mobile host may be
   different 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., stub 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
   support is focused at the network layer.

   The Mobile IP protocol (MIP) and architecture addresses the
   fundamental characteristics of a ETS user migrating to a foreign
   network and attempting to contact other users.  One can also make an
   arguement that the percieved needs of an ETS user, e.g., labeling
   traffic to distinguish it from other flows can also be acheived
   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.

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
   supporting ETS.

   The Network Mobile (NEMO) working group has just recently been formed
   to address the issues that arise when entire networks move in
   relation 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
   working 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



Carlberg                    Expires December 9, 2004           [Page 11]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   subject area of context transfer is an important one and it has the
   potential to constructively support ETS.

4.8 Differentiated Service (Diff-Serv)

   There are a number of examples where Diff-Serv [22] 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 for
   Diff-Serv code points.  An extensive discussion on Diff-Serv
   deployment is outside the scope of this document.

   [23] presents common examples of various codepoints used for well
   known applications.  The document does not recommend these
   associations as being standard or fixed.  Rather, the examples in
   [23] 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
   mechansisms, 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
   particular set of users (in the case of this document, ETS users) are
   prime targets for security attacks, or simple misuse.  Hence,
   administrators that choose to incorporate additional
   protocols/services to support 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 for comments and suggestions on the initial



Carlberg                    Expires December 9, 2004           [Page 12]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   version of this draft.


7. References

7.1 Normative Reference

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

7.2 Informative References

   2  Carlberg, K., Atkinson, R., "Requirements for Supporting ETS in
      Stub Domains", Internet Draft, Work In Progress, June 2003

   3  Carlberg, K,. et. al, "Framework for Supporting ETS in IP
      Telephony", Internet Draft, Work In Progress, June, 2003

   4  Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
      2002

   5  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
      March 1997

   6  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label
      Switching Architecture", RFC 3031, January 2001.

   7  Le Faucheur, F., et al, "MPLS Support of Differentiated Services",
      RFC 3270, May 2002

   8  Braden, R., et al, "Resource Reservation Protocol (RSVP) Version
      1 Functional Specification", RFC 2205, September 1997

   9  Awduche, D., "RSVP-TE: Extensions to RSVP for LSP Tunnels",
      RFC 3209, December 2001

   10 Herzog, S., "RSVP Extensions for Policy Control", RFC 2750,
      January 2000

   11 Durham, D., et al, "The COPS (Common Open Policy Service)
      Protocol", RFC 2748, January 2000.

   12 Herzog, S., et al, "COPS Usage for RSVP", RFC 2749, January
      2000

   13 Chan, K., et al, "COPS Usage for Policy Provisioning (COPS-PR)",
      RFC 3084, March 2001




Carlberg                    Expires December 9, 2004           [Page 13]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   14 Schoenwaelder, J., "Overview of the 2002 IAB Network Management
      Workshop", RFC 3535, May 2003

   15 "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"

   16 "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.

   17 Meyer, D., Fenner, B., "Multicast Source Discovery Protocol
      (MSDP)", RFC 3618, October 2003

   18 Estrin, D., et al, "Protocol Independent Multicast-Sparse Mode
      (PIM-SM): Protocol Specification", RFC 2362, June 1998

   19 Guttman, C., et al, "Service Location Protocol, Version 2",
      RFC 2608, June 1999.

   20 Partridge, C., et al, "Host Anycasting Service", RFC 1546,
      November 1993

   21 Hinden, R., Deering, S., "Internet Protocol Version 6 (IPv6)
      Addressing Architecture", RFC 3513, April 2003

   22 Nichols, K., et al, "Definition of the Differentiated Services
      Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
      December 1998.

   23 Baker, F., et. al., "Configuration Guidelines for DiffServ
      Service Classes", Internet Draft, Work In Progress, Feb 2004



8.  Author's Addresses

   Ken Carlberg
   G11
   123a Versailles Circle
   Baltimore, MD
   USA
   carlberg@g11.org.uk

Full Copyright Statement



Carlberg                    Expires December 9, 2004           [Page 14]

Internet Draft        ETS Single Domain Framework           June 9, 2004


   "Copyright (C) The Internet Society (2004). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided as an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OR
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



























Carlberg                    Expires December 9, 2004           [Page 15]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/