Internet DRAFT - draft-mcgregor-ieprep-ip-bridging-bcp
draft-mcgregor-ieprep-ip-bridging-bcp
IEPREP Working Group Pat McGregor
Internet Draft Richard Kaczmarek
Expires December 23, 2003 Nyquetek Inc
Category: Best Current Practice Dennis Berg
File: draft-mcgregor-ieprep-bridging-bcp-00.txt Janet Gunn
CSC
June 2003
MPLS IP Bridging Configuration Guidance for IEPREP
Status of this Memo
This document is an Internet-Draft and is subject to all provisions of
Section 10 of RFC2026.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
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.
This Internet-Draft will expire on December 23, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
An Internet Emergency Preparedness (IEPREP) telephony service IP
Bridging topology using Multi-Protocol Label Switching (MPLS) should
provide Emergency Telecommunications Service (ETS) using a) Session
Initiation Protocol (SIP) Priority header value of "emergency", b)
Session Description Protocol (SDP) attribute experimental parameters to
designate the call (session) as either a National Emergency call,
International Emergency call, or both, c) MEGACO context descriptors of
McGregor et al Expires December 23, 2003 [Page 1]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
priorities 1-6 and emergency indication, and d) MPLS E-LSPs with a
dedicated codepoint specifying application of ETS Per-Hop Behavior
(PHB). IP Differentiated Services marking should use specified code
points allocated from the Experimental and Local Use pool (pool 2) to
designate the traffic as either National Emergency or International
Emergency for corresponding PHB use. Signaling between the Signaling
Gateway (SG) and Media Gateway Controller (MGC) should apply the MTP3
SS7 protocol over the M2UA adaptation protocol for use of the Stream
Control Transmission Protocol (SCTP). Support is suggested for work in
progress on defining a SIP Resource Priority header and defining a SIP
telephone url extension for calling party category designation.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terms and Definitions . . . . . . . . . . . . . . . . . . 4
2. IP Bridging Topology . . . . . . . . . . . . . . . . . . . . 4
3. MLPS LSPs . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. MEGACO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 8
7. Differentiated Services Code Points . . . . . . . . . . . . . 9
8. Signaling . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
A. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 13
McGregor et al Expires December 23, 2003 [Page 2]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
1. Introduction
The Internet Emergency Preparedness (IEPREP) Working Group charter
notes that effective telecommunications capabilities are imperative to
facilitate immediate recovery operations for serious disaster events,
and that the Internet community needs to consider how it can best
support emergency management and recovery operations. This document
presents recommendations for Emergency Telecommunications Service (ETS)
telephony application design with existing protocols in an IP Bridging
topology.
User requirements for IP-based networks to enable and support an
authorized emergency telecommunications service (ETS)for use by
authorities to organize and coordinate emergency and disaster relief
operations are described in [IEPREP Rqmts]. It provides a basis from
which ETS can be negotiated to provide user-acceptable communications.
The requirements relate to user expectation and are general,
functional, and intended to provide wide latitude in implementation
options.
A framework for supporting authorized emergency related communication
within the context of IP telephony has been presented in [IEPREP
Frame]. The framework includes a series of objectives that reflect
a general view of how authorized emergency service, in line with the
Emergency Telecommunications Service (ETS), should be realized within
today's IP architecture and service models. From these objectives, a
corresponding set of protocols and capabilities are presented which
provide a more specific set of recommendations regarding existing IETF
protocols. This current paper builds on the framework to provide
specific guidance for implementing an ETS using existing protocols.
This document makes a distinction between National Emergency
applications and International Emergency applications based on the
notion that different countries may require different ETS treatments
for national versus international emergency applications. (In both
cases, the applications are assumed to be within the context of
authorized and authenticated uses for official purposes versus the more
commonly considered public emergency service.) Within the USA,
National Emergency telephony applications are recognized in SS7 call
setup by the Initial Address Message (IAM) Calling Party Category (CPC)
being set to the High Probability of Completion (HPC) codepoint as
specified in [ANSI HPC]. When National Emergency applications are
noted below, it is assumed that the call has been recognized as such by
some mechanism like HPC. Similarly, the ITU is addressing how to
signal international emergency calls [ITU IEPS] and the same assumption
of recognition is applied.
1.1 Motivation
The motivation for this draft is to initiate work on providing
appropriate guidance to the international community on the design of
Emergency Telecommunications Service (ETS) telephony applications using
existing protocols.
McGregor et al Expires December 23, 2003 [Page 3]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
1.2 Terms and Definitions
The following acronyms are exploded for clarity:
AT = Access Tandem
CSN = Circuit Switched Network
EF = Expedited Forwarding
E-LSP = EXP-inferred-PSC LSPs
ETS = Emergency Telecommunications Service
EXP = field in MPLS label
GW = Gateway (CSN to IP, or IP to CSN)
LSP = Label Switched Path
LSR = Label Switching Router
MG = Media Gateway
MGC = Media Gateway Controller
MPLS = Multi-Protocol Label Swtiching
PHB = Per Hop Behavior
PSC = PHB Scheduling Class
SG = Signaling Gateway
STP = Signal Transfer Point
TDM = Time Division Multiplexing
2. IP Bridging Topology
The IP Bridging Topology is defined in [IEPREP Term] and is sometimes
known as "IP in the Middle" of two CSNs. In this topology, a CSN phone
of any type initiates (dials) a call to another CSN phone with an IP
core between the two CSNs.
This topology should simplistically look like this:
McGregor et al Expires December 23, 2003 [Page 4]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
Circuit Internet Circuit
Switched IP or IP Switched
Network Ingress IP Segment Egress Network
-----------+ +--------------+ +-----------
| +----+ | IP | +----+ |
CSN | | | | | | | | CSN
Phone ------->| GW |----------------------->| GW |-------->Phone
| | | | | | | |
| +----+ | | +----+ |
-----------+ +--------------+ +-----------
Figure 1. Topology "IP Bridging"
For the purposes of this document, the topology is further elaborated
to explode the CSN elements into ATs and STPs, and to explode the IP
segment into access and egress SGs, MGs, and MGCs, and to show core
LSRs, as portrayed below in Figure 2.
--------------+ +----+ +----+ +----------
| | | | | |
STP.....|....|.SG | | SG.|....|....STP
: | | : | | : | | :
: | | : | +--------------+ | : | | :
: | | MGC| | | | MGC| | :
: | | : | | | | : | | :
: | | : | | | | : | | :
AT ------->| MG |------LSR -----LSR----->| MG |--------> AT
| | | | | | | |
| +----+ | | +----+ |
-----------+ +--------------+ +-----------
Figure 2. Exploded Topology "IP Bridging"
This explosion is intended to portray a possible CSN Local Exchange
Carrier transiting an IP Interexchange Carrier. Note that although the
topology shows the SG connected directly to the MGC and the MGC
connected directly to the MG, these connections should be viewed as
logical connections physically formed by LSPs through the LSRs, with
the SG, MGC, and MG all actually connected to the LSR.
The baseline telephony application design for this topology is assumed
to be bearer traffic from AT to MG and MG to AT via conventional TDM
trunks and from MG to LSR to LSR to MG via LSPs providing EF PHB
supporting RTP media exchange between the MGs. The signaling is
assumed to be conventional SS7 [SS7] from AT to STP to SG and SS7 over
IP using M2UA [M2UA] over SCTP [SCTP] between the SG and MGC. The MGC
is assumed to signal with the MG using MEGACO [MEGACO], and signaling
between the MGCs is assumed to be SIP [SIP] with telephony extensions
[SIP-T].
McGregor et al Expires December 23, 2003 [Page 5]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
3. MLPS LSPs
The recommended practice is to separate ETS traffic treatment from
other traffic treatment by the use of a dedicated codepoint in E-LSPs
to specify application of an ETS PHB versus dedicating LSPs to ETS. It
is recognized that MPLS LSPs [MPLS] have very limited resources for
traffic differentiation, and allocating a significant part of the
resources for the nominally rare but occasionally heavy ETS traffic may
be viewed as wasteful. However, the alternative of creating a separate
ETS topology of LSPs presents greater difficulties because of the
ubiquitous requirement for ETS support coupled with its rare use
leading to significant maintenance and operating challenges. It is
thought to be much more efficient and less painful to maintain an
enhancement on commonly used LSPs than to maintain a complete set of
duplicate LSPs.
E-LSPs [MPLS Diff] are recommended as the basic MPLS resource between
nodes for ease of maintenance and effective scaling. Within E-LSPs,
assignment of PHBs to the eight Differentiated Services codepoints is a
matter of local administration. The recommended practice is that one
of the codepoints (6) be dedicated to an ETS PHB.
The ETS PHB is not a standard PHB and hence is also a matter of local
administration. It is suggested that an ETS PHB be documented for
development as an RFC.
4. SIP
SIP [SIP] has a Priority header field to indicate the urgency of the
request as perceived by the client. The Priority header field
describes the priority that the SIP request should have to the
receiving human or its agent. For example, it may be factored into
decisions about call routing and acceptance. For these decisions, a
message containing no Priority header field SHOULD be treated as if it
specified a Priority of "normal". The Priority header field does not
influence the use of communications resources such as packet forwarding
priority in routers or access to circuits in PSTN gateways, and hence
is of limited relevance in configuring an ETS. The header field can
have the values "non-urgent", "normal", "urgent", and "emergency", but
additional values can be defined elsewhere. Consistent with the
RECOMMENDED practice that the value of "emergency" only be used when
life, limb, or property are in imminent danger, the recommended
practices is that ETS calls be pecified as "emergency".
As noted in [SIP Pri], currently SIP does not include a mechanism that
allows a request originator to indicate to SIP element that it wishes
the request to invoke resource prioritization. (The SIP Priority header
field described above deals only with user perception.) To address
this need, the referenced work in progress adds a SIP protocol element
that labels certain SIP requests. In particular, a new SIP header field
for communications resource priority, called Resource-Priority, is
McGregor et al Expires December 23, 2003 [Page 6]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
documented. This header field, once achieving RFC status, MAY be used
by SIP user agents, including gateways, to influence their treatment of
SIP requests, including the priority afforded to ETS calls. For
gateways interfacing to CSNs, the behavior translates into analogous
schemes in the CSN, in both the CSN-to-IP and IP-to-CSN directions.
The referenced work in progress describes the syntax of the Resource-
Priority header field as follows:
Resource-Priority _ "Resource-Priority" HCOLON Resource-value
Resource-value _ namespace "." priority
namespace _ alphanum / "-"
priority _ alphanum / "-"
Resource-Priority: namespace.priority
The Resource-value parameter in the Resource-Priority header indicates
the resource priority desired by the request originator.
The resource value is formatted as "namespace" "." "priority value".
The value is drawn from the namespace identified by the namespace
token. Namespaces and priorities are case-independent ASCII. Each
namespace has at least one priority value. Namespaces and priority
values within each namespace are to be registered with IANA.
This paper suggests support be given to the referenced work in progress
and that an "ets" namespace be suggested for inclusion in it. The
"ets" namespace would have priority values of 1,2,3,4,5,6 where 1 is
the highest priority and 6 is the lowest priority. Priorities 1-5 are
to be administered in alignment with the five priorities specified by
the wireless community for Wireless Priority Service [WPS]. Priority 6
is to be used for all other calls. The alignment with the Wireless
Priority Service will enable direct IP support for priority wireless
call transport. Where wireless calls interwork with CSNs before
reaching the IP transit network, the WPS priority signaling has not yet
been definitized, although use of MLPP [MLPP] signaling appears to be
attractive.
The SIP is used to signal call setup between MGCs. Telephony
extensions to SIP permit use of a telephone number URL in the "From"
field, e.g.,
From: tel:123-456-7890
Currently work is in progress [SIP CPC] to add the Calling Party
Category (CPC) as an extension to this form of url, permitting the SS7
CPC HPC value to be mapped as:
McGregor et al Expires December 23, 2003 [Page 7]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
From: tel:123-456-7890;cpc=priority
This work will greatly simplify call setup priority treatment of HPC
calls providing a direct mapping of the SS7 IAM CPC parameter as part
of SIP. To the extent that the SIP Resource Priority header provides
an ETS priority, the url cpc parameter may appear redundant and more
limited. However, the direct IAM – SIP parameter mapping is viewed as
sufficiently valuable to justify independent support.
The SIP url cpc parameter does not yet appear to have reached RFC
status, and the general guidance on use of the telephone url is to
disregard the url if any parameter is not recognized. Accordingly, it
is suggested that support be given to standardizing the cpc parameter,
but that it not be used until it is standardized.
5. MEGACO
The MEGACO [MEGACO] protocol provides the means for the MGC to specify
the interconnection of traffic between a TDM circuit and an RTP session
at the MG. MEGACO includes a ContextRequest parameter for "priority"
and a ContextRequest parameter (Boolean) to indicate "emergency". Both
parameters are optional.
The priority is used for a context in order to provide the MG with
information about a certain precedence handling for a context. The
MGC can also use the priority to control autonomously the traffic
precedence in the MG in a smooth way in certain situations (e.g.
restart), when a lot of contexts must be handled simultaneously.
The "priority" parameter is specified to have a range of priority
values 0-15. This ETS paper recommends the practice of the ETS using
priorities 1-6 in alignment with the SIP Resource-Priority header and
Wireless Priority Service conventions described in Section 4. Priority
value 0 should be reserved. It is suggested that work be initiated to
establish these assignments as standard.
The indicator for an emergency call is provided to allow a preference
handling in the MG. This ETS paper recommends the practice of applying
the "emergency" indicator for ETS calls.
6. SDP Attributes
When a call is initiated, the SDP is applied to describe the session
request between MGCs and between the MGC and MG (as a MEGACO variant).
The SDP [SDP] provides the means to ascribe to a session a set of
attributes by use of the attribute parameter. Values (character
strings) for the attribute parameter may be drawn from the set of
standard values with corresponding standard interpretations, or be
McGregor et al Expires December 23, 2003 [Page 8]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
chosen in accordance with local administration with local
interpretation (as long as they do not conflict with a standard value).
The recommended practice is to specify ETS sessions as either National
Emergency sessions using the attribute parameter value "x-NatETS"
(where the leading "x" is understood to be customary to designate non-
standard values) or International Emergency sessions using the
attribute parameter value "x-IntETS". It is suggested that an effort
be initiated to standardize these attribute values.
The rationale for including an ETS designation via the SDP attribute
parameter is that certain session treatments may be influenced by
recognition of the session as an ETS session and that inclusion in the
session description can be more general in application than telephony.
7. Differentiated Services Code Points
The Differentiated Services [Diff Serv] field of the IP packet has its
range of codepoints divided into three pools, the second of which is
designated for experimental and local use. The recommended practice is
to assign two values from this pool to designate International
Emergency and National Emergency service differentiations. More
precisely, the following two values are recommended, subject to
confirmation that they do not conflict with any other known
assignments:
National Emergency = 011111
International Emergency = 011011
It is suggested that work be initiated to standardize Differentiated
Services codepoints for International Emergency and National Emergency
traffic.
It is recommended that the two Differentiated Services codepoints map
into the common ETS MPLS Differentiated Services codepoint. The
distinct IP level codepoints are expected to be of some use in
providing differentiated services between the two types of traffic upon
egress from (and possibly access to) the LSPs. (This will be more true
in topologies other than the IP Bridging topology considered here.)
It should be noted that Differentiated Services reflexivity is the
subject or work in progress [IEPREP Reflex] and it is suggested here
that such work be supported.
8. Signaling
The signaling between the CSN segment and IP segment for the topology
under consideration is SS7. To provide ETS service to calls signaled
over this interface, either a designation mechanism must be applied in
the SS7 IAM message, or the signaling must be known to relate to ETS
calls (e.g., by virtue of the dedicated CSN ETS facilities over which
McGregor et al Expires December 23, 2003 [Page 9]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
the signaling is arriving). Within the USA, the IAM Calling party
Category (CPC) High Probability of Completion (HPC) codepoint is used
to signal calls as ETS.
When a SG receives a call recognized as an ETS call (e.g., by the IAM
CPC HPC codepoint), it must signal this recognition to the MGC. It is
recommended that this signaling be accomplished by use of the SS7 ISUP
IAM message communicated over SS7 MTP3 over M2UA over SCTP over IP.
The IAM being sent should apply the same mechanism as used to identify
an ETS call as the IAM being received (e.g., the HPC codepoint).
Similarly the MTP3 congestion priority assigned to the IAM being sent
should be the same as the congestion priority on the IAM being received
(e.g., in the USA, IAMs with HPC set have a congestion priority of 1
where all other IAMs have a lower congestion priority of zero).
The IAM should be sent from the SG to the MGC over an E-LSP using the
EXP ETS codepoint.
9. Security Considerations
Where an ETS call is carried from PSTN to PSTN via one telephony
carrier's backbone IP network, as considered here, very little IP-
specific security support is required. The user is assumed to have
authenticated his entitlement to ETS service in the originating CSN
segment and the indication of the call as an ETS call across the CSN to
IP interface is presumed to be without issue at this time.
Conversely, the gateway back into the CSN must similarly signal the
call as an ETS call. A secure link between the gateways may be set up
using IPSec or SIP security functionality.
10. IANA Considerations
This document introduces several names and values that can be
locally administered, but which are suggested as considerations for
IANA. In particular:
- An SIP Priority Resource header namespace of "ets" and priority
values of 1-6 be specified for ETS (assuming the work in progress
becomes an RFC).
- The MEGACO priority descriptor values 1-6 be assigned for ETS
application.
- SDP attribute values of "NatETS" and "IntETS" be specified.
- Differntiated Services codepoints of National Emergency = 011111
and International Emergency = 011011 be specified.
It is suggested that work be initiated to register such names and
values with IANA.
McGregor et al Expires December 23, 2003 [Page 10]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
Normative References
[Diff Serv] Nichols, K., Blake, S., Baker, F., Black, D., "Definition
of the Differentiated Services Field (DS Field) in the IPv4 and IPv6
Headers", RFC 2474, December 1998.
[IEPREP Term] Polk, J., "Internet Emergency Preparedness (IEPREP)
Telephony Topology Terminology", RFC 3523, April 2003.
[MPLS diff] Le Faucheur, F. et al, "MPLS Support of Differentiated
Services", RFC 3270, May 2002.
[MEGACO] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B.,
Marconi, Segers, J., "MEGACO Protocol Version 1.0", RFC 3015, November
2000.
[M2UA] Morneault, K., Dantu, R., Sidebottom, G., Bidulock, B., Heitz,
J., "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) -
User Adaptation Layer", RFC 3331, September 2002.
[MPLS] Rosen, E., Viswanathan, A., Callon, R., "Multiprotocol Label
Switching Architecture", January 2001.
[MPLS Diff] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., Heinanen, J., "Multi-Protocol Label
Switching (MPLS) Support of Differentiated Services", RFC 3270, May
2002.
[SCTP] Stewart, R., et al., "Stream Control Transmission Protocol",
RFC2960, October 2000.
[SDP] Handley, M., Jacobson, V., "SDP: Session Description protocol",
RFC 2974, October 2000.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session
Initiation Protocol", RFC 3261, June 2002.
[SIP Pri] Schulzrinne, H., "Requirements for Resource Priority
Mechanisms for the Session Initiation Protocol (SIP)", RFC 3487,
February 2003.
[SIP-T] Vemuri, A., Peterson, J., "Session Initiation Protocol for
Telephones (SIP-T): Context and Architectures", RFC 3372,
September 2002.
McGregor et al Expires December 23, 2003 [Page 11]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
Non-Normative References
[ANSI HPC] ANSI, "Signaling System No. 7(SS7) High Probability of
Completion (HPC) Network Capability, ANSI T1.631-1993, (R1999).
[IEPREP Frame] Carlberg, K., Brown, I., Beard, C., "Framework for
Supporting ETS in IP Telephony", Work in Progress, Internet-Draft,
October 2002.
[IEPREP Reflex] Atarashi, R., Baker, F., "Reflexive DSCP Policy", Work
in Progress, Internet-Draft, October 2002.
[IEPREP Rqmts] Carlberg, K., Atkinson, R., "General Requirements for
Emergency Telecommunications Service", Work in Progress, Internet-
Draft, January, 2003.
[IEPREP IP Rqmts] Carlberg, K., Atkinson, R., "IP Telephony
Requirements for Emergency Telecommunications Service", Work In
Progress, Internet- Draft, January, 2003.
[ITU IEPS] "Description of an International Emergency Preference Scheme
(IEPS)", ITU-T Recommendation E.106 March, 2002.
[ITU MLPP] ITU, "Multi-Level Precedence and Preemption Service, ITU
Recommendation I.255.3, July, 1990.
[SIP CPC] Peterson, J. "The Calling Party's Category tel URL
Parameter",
Work in Progress, Internet-Draft, October 27, 2002.
[SS7] International Telecommunications Union, "Signaling System No. 7;
ISDN User Part Signaling procedures", ITU-T Q.764, September 1997,
<http://www.itu.int>.
[ISUP SIP] Camarillo, G., Roach, A., Peterson, J. and L. Ong, "ISUP to
SIP Mapping", Work in Progress, Internet-Draft.
McGregor et al Expires December 23, 2003 [Page 12]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
Appendix A. Notes
Appendix B. Acknowledgments
Authors' Addresses
Pat McGregor
Nyquetek Inc
8397 Piping Rock
Millersville, MD 21108 USA
EMail: pat_mcgregor@msn.com
Phone: 410-703-4486
Richard Kaczmarek
Nyquetek Inc
c/o CSC
15000 Conference Center Dr
Chantilly, VA
Email: Richard.Kaczmarek@DynCorp.com
Phone: 703-818-5894
Dennis Berg
CSC
15000 Conference Center Dr
Chantilly, VA
Email: Dennis.Berg@DynCorp.com
Phone: 703-818-4608
Janet Gunn
CSC
15000 Conference Center Dr
Chantilly, VA
Email: Janet.Gunn@DynCorp.com
Phone: 703-818-4725
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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
McGregor et al Expires December 23, 2003 [Page 13]
Internet-Draft IEPREP IP Bridging MPLS BCP June 2003
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 on 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 OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
McGregor et al Expires December 23, 2003 [Page 14]
