draft-ietf-ieprep-domain-req-04.txt   draft-ietf-ieprep-domain-req-05.txt 
Internet Engineering Task Force Ken Carlberg Internet Engineering Task Force Ken Carlberg
Feb 4, 2005 Sep 12, 2005
Emergency Telecommunications Services (ETS) Requirements Emergency Telecommunications Services (ETS) Requirements
for a Single Administrative Domain for a Single Administrative Domain
<draft-ietf-ieprep-domain-req-04.txt> <draft-ietf-ieprep-domain-req-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract Abstract
This document presents a list of requirements in support of Emergency This document presents a list of requirements in support of Emergency
Telecommunications Service (ETS) within a single administrative Telecommunications Service (ETS) within a single administrative
domain. This document is an extension of the General Requirements of domain. This document is an extension of the General Requirements of
[rfc3689] and focuses on a more specific set of administrative [rfc3689] and focuses on a more specific set of administrative
constraints and scope. Solutions to these requirements are not constraints and scope. Solutions to these requirements are not
presented in this document. presented in this document.
1. Introduction 1. Introduction
skipping to change at page 3, line 8 skipping to change at page 3, line 11
source or the destination of a flow of IP packets. As a general source or the destination of a flow of IP packets. As a general
rule, it does not forward traffic that is destined for other rule, it does not forward traffic that is destined for other
domains. The odd exception to this statement is the case of domains. The odd exception to this statement is the case of
Mobile IP and its use of "dog-leg" routing to visiting hosts Mobile IP and its use of "dog-leg" routing to visiting hosts
located in foreign networks. An enterprise network is an example located in foreign networks. An enterprise network is an example
of a stub domain. of a stub domain.
1.1 Previous Work 1.1 Previous Work
A list of General Requirements for support of ETS is presented in A list of General Requirements for support of ETS is presented in
[2]. The document articulates requirements when considering the [rfc3689]. The document articulates requirements when considering
broad case of supporting ETS over the Internet. Since that document the broad case of supporting ETS over the Internet. Since that
is not constrained to specific applications, administrative document is not constrained to specific applications, administrative
boundaries, or scenarios, the requirements contained within it tend boundaries, or scenarios, the requirements contained within it tend
to be quite general in their description and scope. This follows the to be quite general in their description and scope. This follows the
philosophy behind its inception in that the General Requirements are philosophy behind its inception in that the General Requirements are
meant to be a baseline followed (if necessary) by more specific meant to be a baseline followed (if necessary) by more specific
requirements that pertain to a more narrow scope. requirements that pertain to a more narrow scope.
The requirements presented below in Section 3 are representative of The requirements presented below in Section 3 are representative of
the more narrow scope of a single administrative domain. As in the the more narrow scope of a single administrative domain. As in the
case of [rfc3689], the requirements articulated in this document case of [rfc3689], the requirements articulated in this document
represent aspects to be taken into consideration when solutions are represent aspects to be taken into consideration when solutions are
skipping to change at page 3, line 44 skipping to change at page 3, line 47
QoS mechanisms are also within the scope of this document. These QoS mechanisms are also within the scope of this document. These
mechanisms may reside at the application, transport, or IP network mechanisms may reside at the application, transport, or IP network
layer. While QoS mechanisms may exist at the link/physical layer, layer. While QoS mechanisms may exist at the link/physical layer,
this document would only consider potential mappings of labels or this document would only consider potential mappings of labels or
code points. code points.
Finally, since this document focuses on a single administrative Finally, since this document focuses on a single administrative
domain, we do not make any further distinction between transit and domain, we do not make any further distinction between transit and
stub domains within this document. stub domains within this document.
2.1 Out of Scope 2.1 Out of Scope:
Resources owned or operated by other administrative authorities are Resources owned or operated by other administrative authorities are
outside the scope of this document. One example are SIP servers that outside the scope of this document. One example are SIP servers that
operate in other domains. Another example are access links operate in other domains. Another example are access links
connecting the stub domain and its provider. Controlling only 1/2 of connecting the stub domain and its provider. Controlling only 1/2 of
a link (the egress traffic from the stub) is considered insufficient a link (the egress traffic from the stub) is considered insufficient
for including inter-domain access links as a subject for this for including inter-domain access links as a subject for this
document. document.
3. Requirements 3. Requirements
skipping to change at page 4, line 34 skipping to change at page 4, line 39
in requirements because there may be fewer bits (a smaller field) in requirements because there may be fewer bits (a smaller field)
available at the network layer than in the transport or application available at the network layer than in the transport or application
layer. layer.
3.2 Proxies 3.2 Proxies
Proxies MAY set ETS labels on behalf of the source of a flow. This Proxies MAY set ETS labels on behalf of the source of a flow. This
may involve removing labels that have been set by upstream node(s). may involve removing labels that have been set by upstream node(s).
If proxies take such action, then the security measures discussed in If proxies take such action, then the security measures discussed in
[2] MUST be considered. More discussion about security in the single [rfc3689] MUST be considered. More discussion about security in the
domain context is discussed in section 5. single domain context is discussed in section 5.
3.3 QoS mechanisms 3.3 QoS mechanisms
Quality of Service (QoS) mechanisms, at either the network or [rfc3689] defines a label as an identifier, and the set of
characteristics associated with the label as policy. However,
Quality of Service (QoS) in the traditional sense of delay or
bandwidth is not automatically bound to a label. MPLS [rfc3031] is
an example of a labeling mechanism that can provide specific QoS or
simply traffic engineering of labeled flows.
In the context of ETS, QoS mechanisms, at either the network or
application layer, SHOULD be used when networks cannot be over- application layer, SHOULD be used when networks cannot be over-
provisioned to satisfy high bursts of traffic load. Examples can provisioned to satisfy high bursts of traffic load. Examples can
involve bridging fiber networks to wireless subnetworks, or remote involve bridging fiber networks to wireless subnetworks, or remote
subnetworks connected over expensive bandwidth constrained wide area subnetworks connected over expensive bandwidth constrained wide area
links. links.
Note well. Over-provisioning is a normal cost-effective practice Note well. Over-provisioning is a normal cost-effective practice
amongst network administrators/engineers. The amount of over- amongst network administrators/engineers. The amount of over-
provisioning can be a topic of debate. More in-depth discussion on provisioning can be a topic of debate. More in-depth discussion on
this topic is presented in the companion Framework document of this topic is presented in the companion Framework document of
skipping to change at page 6, line 8 skipping to change at page 6, line 21
than best effort is probably the service that most ETS users would than best effort is probably the service that most ETS users would
expect when the communication system is stressed and overall quality expect when the communication system is stressed and overall quality
has degraded. However, the concept of best available service should has degraded. However, the concept of best available service should
also be considered under such stressed conditions. Further, a also be considered under such stressed conditions. Further, a
measure of degraded service may also be desirable to ensure a measure measure of degraded service may also be desirable to ensure a measure
of communication versus none. These services may be made available of communication versus none. These services may be made available
at the network or application layer. at the network or application layer.
4.2 Redundancy 4.2 Redundancy
The issue of making network fault tolerant is important and yet not The issue of making networks fault tolerant is important and yet not
one that can be easily articulated in terms of requirements. one that can be easily articulated in terms of requirements of
Redundancy in connectivity and nodes (be it routers or servers) is protocols. Redundancy in connectivity and nodes (be it routers or
probably the most common approach taken by network administrators, servers) is probably the most common approach taken by network
and it can be assumed that administrative domains apply this approach administrators, and it can be assumed that administrative domains
in various degrees to there own resources. apply this approach in various degrees to there own resources.
5. Security Considerations 5. Security Considerations
This document recommends that readers review and follow the comments This document recommends that readers review and follow the comments
and requirements about security presented in [rfc3689]. Having said and requirements about security presented in [rfc3689]. Having said
that, there tends to be many instances where intra-domain security is that, there tends to be many instances where intra-domain security is
held at a lower standard (i.e., less stringent) that inter-domain held at a lower standard (i.e., less stringent) that inter-domain
security. For example, while administrators may allow telnet service security. For example, while administrators may allow telnet service
between resources within an administrative domain, they would only between resources within an administrative domain, they would only
allow SSH access from other domains. allow SSH access from other domains.
skipping to change at page 7, line 7 skipping to change at page 7, line 18
non-secure manner. As a result, it may be best to constrain non-secure manner. As a result, it may be best to constrain
the use of these objects to read-only by MIB managers. the use of these objects to read-only by MIB managers.
- Finally, any MIB defining writable objects should carefully - Finally, any MIB defining writable objects should carefully
consider the security implications of an SNMP compromise on consider the security implications of an SNMP compromise on
the mechanism(s) being controlled by those writable MIB the mechanism(s) being controlled by those writable MIB
objects. objects.
6. Acknowledgements 6. Acknowledgements
Thanks to Ran Atkinson, James Polk, and Ian Brown for comments on Thanks to Ran Atkinson, James Polk, Scott Bradner, Jon Peterson, and
previous versions of this draft. Ian Brown for comments on previous versions of this draft.
7. References 7. References
7.1 Normative Reference 7.1 Normative Reference
[rfc3668] Bradner, S., "Intellectual Property Rights in IETF [rfc3668] Bradner, S., "Intellectual Property Rights in IETF
technology", BCP 79, RFC 3668, February 2004 technology", BCP 79, RFC 3668, February 2004
7.2 Informative References 7.2 Informative References
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[rfc3031] Rosen, E., et. al., "Multiprotocol Label Switching
Architecture", RFC3031, January 2001
[rfc3689] Carlberg, K., Atkinson, R., "General Requirements for [rfc3689] Carlberg, K., Atkinson, R., "General Requirements for
Emergency Telecommunications Service", RFC3689 Emergency Telecommunications Service", RFC3689
Feb 2004 Feb 2004
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[frame] Carlberg, K., "A Framework for Supporting ETS in Stub [frame] Carlberg, K., "A Framework for Supporting ETS in Stub
Domains", Internet Draft, Work in Progress, Domains", Internet Draft, Work in Progress,
draft-ieprep-domain-frame-02.txt, June 2003. draft-ieprep-domain-frame-02.txt, June 2003.
8. Author's Addresses 8. Author's Addresses
Ken Carlberg Ken Carlberg
G11 G11
123a Versailles Circle 123a Versailles Circle
Baltimore, MD Baltimore, MD
USA USA
carlberg@g11.org.uk carlberg@g11.org.uk
Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2004). This document is subject The IETF takes no position regarding the validity or scope of any
to the rights, licenses and restrictions contained in BCP 78, and Intellectual Property Rights or other rights that might be claimed to
except as set forth therein, the authors retain all their rights. pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Disclamer Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/