SPEERMINT WG J. Elwell
Internet-Draft Siemens Enterprise Communications
Intended status: Informational Limited
Expires: August 20, 2007 B. Rodrig
Avaya
February 16, 2007
Use cases for Enterprise Peering using the Session Initiation Protocol
(SIP)
draft-elwell-speermint-enterprise-usecases-00.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 August 20, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
Work in the SPEERMINT Working Group has focused to some extent on
peering between carrier VoIP Service Providers (VSP). This draft
describes some use cases involving SIP peering between enterprise
VSPs, with and without the involvement of carrier VSPs, and also
peering between enterprise VSPs and carrier VSPs. It also discusses
Elwell & Rodrig Expires August 20, 2007 [Page 1]
Internet-Draft Enterprise peering February 2007
some of the key technical considerations applicable to these use
cases.
This work is being discussed on the speermint@ietf.org mailing list.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Direct peering between enterprises . . . . . . . . . . . . 4
3.2. Indirect peering between enterprises via an
intermediate enterprise . . . . . . . . . . . . . . . . . 4
3.3. Indirect peering between enterprises via an
intermediate carrier VSP . . . . . . . . . . . . . . . . . 5
3.4. Indirect peering between enterprises via two
intermediate carrier VSPs . . . . . . . . . . . . . . . . 6
3.5. Direct peering between enterprise and carrier . . . . . . 6
3.6. Indirect peering between enterprise and carrier via an
intermediate carrier VSP . . . . . . . . . . . . . . . . . 7
4. Summary of peering relationship cases . . . . . . . . . . . . 7
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Enterprise user identities . . . . . . . . . . . . . . . . 8
5.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Calling and connected identities . . . . . . . . . . . . . 9
5.4. User agent identities . . . . . . . . . . . . . . . . . . 9
5.5. Signalling Security . . . . . . . . . . . . . . . . . . . 9
5.6. Media and Media Security . . . . . . . . . . . . . . . . . 10
5.7. Transparency . . . . . . . . . . . . . . . . . . . . . . . 11
5.8. Regulatory aspects . . . . . . . . . . . . . . . . . . . . 11
5.9. Management . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security considerations . . . . . . . . . . . . . . . . . . . 12
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
10. Informative References . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Elwell & Rodrig Expires August 20, 2007 [Page 2]
Internet-Draft Enterprise peering February 2007
1. Introduction
Work in the SPEERMINT Working Group has focused to some extent on
peering between carrier VoIP Service Providers (VSP). This draft
describes some use cases involving SIP (RFC 3261 [1])peering (layer 5
peering) between Enterprise VSPs, with and without the involvement of
carrier VSPs, and also peering between enterprise VSPs and carrier
VSPs. It also discusses some of the key technical considerations
applicable to these use cases.
A subset of these use cases has been addressed by the SIP Forum IP
PBX / Service Provider Interoperability specification [12].
This draft is intended to provide input to the SPEERMINT group with
respect to enterprise peering and is not necessarily intended as a
basis for a separate RFC.
2. Overview
The basic requirement of enterprise layer 5 peering is for a User
Agent (UA) belonging to an enterprise A to send a SIP request to a UA
belonging to an enterprise B and to receive a response. One
particular example of a request is a SIP INVITE request, which is
used to establish a session between the two UAs. Within the context
of the session, media will flow between the two UAs. In addition to
INVITE requests, other types of request (e.g., SUBSCRIBE, MESSAGE)
will need to be sent.
The basic requirement for enterprise-carrier peering is for a UA
belonging to enterprise A to send a SIP request to a UA belonging to
carrier B, or vice versa, and to receive a response. The UA in
carrier B could belong to a residential or small business user or
could be a PSTN gateway, for example.
A SIP request will follow a certain path through the peering
entities. Any media established as a result of that SIP request will
not necessarily follow the same path. This draft considers only the
routing of SIP requests.
For the purposes of this draft it is assumed that a proxy is involved
in each enterprise or carrier service provider. This does not
preclude the use of B2BUAs. Also, no assumption is made about the
presence of session border controllers (SBC).
Elwell & Rodrig Expires August 20, 2007 [Page 3]
Internet-Draft Enterprise peering February 2007
3. Use cases
3.1. Direct peering between enterprises
In this use case a proxy in enterprise A is able to route requests
directly to enterprise B. This assumes that enterprise A can obtain
the address of the proxy at enterprise B, e.g., through configuration
or DNS look-up. It also requires the proxy at enterprise B to accept
requests directly from enterprise A. It is likely that some form of
bilateral arrangement will need to be in place for this case to work.
+-----------------------+ +-----------------------+
| Enterprise A | | Enterprise B |
| +------+ +-------+ | | +-------+ +------+ |
| | | | Proxy | | | | Proxy | | | |
| | UA A |----| A |-+------+-| B |----| UA B | |
| +------+ +-------+ | | +-------+ +------+ |
+-----------------------+ +-----------------------+
3.2. Indirect peering between enterprises via an intermediate
enterprise
In this use case a proxy in enterprise A is unable to route requests
directly to enterprise B but is able to do so via an intermediate
enterprise, I. Enterprises A and B each have some form of agreement
in place with enterprise I, which allows them to route requests to
enterprise I and receive requests from enterprise I. This could be
part of a larger federation in which enterprise I acts as an
intermediary between a multiplicity of enterprises.
In this case peering between enterprises A and B is achieved through
a combination of peering between enterprise A and enterprise I and
peering between enterprise I and enterprise B.
A special sub-case of this case is where enterprises A and B are
really different parts of the same enterprise but for some reason do
not have direct connectivity available at the time (e.g., due to
outage or overflow). This sub-case assumes that enterprise I can
obtain the address of the appropriate proxy in part A or B of the
enterprise, e.g. that enterprise I regards these distinct parts of
the enterprise as different domains.
Elwell & Rodrig Expires August 20, 2007 [Page 4]
Internet-Draft Enterprise peering February 2007
+-----------------------+ +-------------+ +-----------------------+
| Enterprise A | |Enterprise I | | Enterprise B |
| +------+ +-------+ | | +-------+ | | +-------+ +------+ |
| | | | Proxy | | | | Proxy | | | | Proxy | | | |
| | UA A |----| A |-+---+--| I |--+---+-| B |----| UA B | |
| +------+ +-------+ | | +-------+ | | +-------+ +------+ |
+-----------------------+ +-------------+ +-----------------------+
3.3. Indirect peering between enterprises via an intermediate carrier
VSP
In this use case a proxy in enterprise A is unable to route requests
directly to enterprise B but is able to do so via an intermediate
carrier VSP, I. Enterprises A and B each have some form of agreement
in place with carrier I, which allows them to route requests to
carrier I and receive requests from carrier I.
In this case peering between enterprises A and B is achieved through
a combination of "peering" between enterprise A and carrier I and
"peering" between carrier I and enterprise B. The term "peering" is
used here because in many respects the relationship between an
enterprise and a carrier is similar to a peering relationship.
However, in some respects the two VSPs (enterprise and carrier) are
not regarded as peers, e.g., charging, regulatory matters.
A special sub-case of this case is where enterprises A and B are
really different parts of the same enterprise but for some reason do
not have direct connectivity available at the time (e.g., due to
outage or overflow). This sub-case assumes that carrier I can obtain
the address of the appropriate proxy in part A or B of the
enterprise, e.g. that carrier I regards these distinct parts of the
enterprise as different domains.
+-----------------------+ +-------------+ +-----------------------+
| Enterprise A | | Carrier I | | Enterprise B |
| +------+ +-------+ | | +-------+ | | +-------+ +------+ |
| | | | Proxy | | | | Proxy | | | | Proxy | | | |
| | UA A |----| A |-+---+--| I |--+---+-| B |----| UA B | |
| +------+ +-------+ | | +-------+ | | +-------+ +------+ |
+-----------------------+ +-------------+ +-----------------------+
Elwell & Rodrig Expires August 20, 2007 [Page 5]
Internet-Draft Enterprise peering February 2007
3.4. Indirect peering between enterprises via two intermediate carrier
VSPs
In this use case a proxy in enterprise A is unable to route requests
directly to enterprise B but enterprise A is able to route requests
to an intermediate carrier VSP, I, and enterprise B is able to
receive requests from an intermediate carrier J, where I and J have
direct or indirect peering relationships. Thus a request can go from
A via I and J to B.
In this case peering between enterprises A and B is achieved through
a combination of "peering" between enterprise A and carrier I,
peering between carriers I and J, and "peering" between carrier J and
enterprise B.
A special sub-case of this case is where enterprises A and B are
really different parts of the same enterprise but for some reason do
not have direct connectivity available at the time (e.g., due to
outage or overflow). This sub-case assumes that carriers I/J can
obtain the address of the appropriate proxy in part A or B of the
enterprise, e.g. that carriers I/J regard these distinct parts of the
enterprise as different domains.
+------------------+ +-----------+ +-----------+ +------------------+
| Enterprise A | | Carrier I | | Carrier J | | Enterprise B |
|+------+ +-------+| | +-------+ | | +-------+ | |+-------+ +------+|
|| | | Proxy || | | Proxy | | | | Proxy | | || Proxy | | ||
|| UA A |-| A |+--+-| I |-+--+-| J |-+--+| B |-| UA B ||
|+------+ +-------+| | +-------+ | | +-------+ | |+-------+ +------+|
+------------------+ +-----------+ +-----------+ +------------------+
3.5. Direct peering between enterprise and carrier
In this use case a proxy in enterprise A is able to route requests
directly to carrier B or vice versa. The UA in carrier B could
belong to a residential or small business user or could be a PSTN
gateway, for example. This assumes that the first VSP can obtain the
address of the proxy at the other VSP, e.g., through configuration or
DNS look-up. It also requires the proxy at the second VSP to accept
requests directly from the first VSP. It is likely that some form of
bilateral arrangement will need to be in place for this case to work.
Elwell & Rodrig Expires August 20, 2007 [Page 6]
Internet-Draft Enterprise peering February 2007
+-----------------------+ +-----------------------+
| Enterprise A | | Carrier B |
| +------+ +-------+ | | +-------+ +------+ |
| | | | Proxy | | | | Proxy | | | |
| | UA A |----| A |-+------+-| B |----| UA B | |
| +------+ +-------+ | | +-------+ +------+ |
+-----------------------+ +-----------------------+
3.6. Indirect peering between enterprise and carrier via an
intermediate carrier VSP
In this use case a proxy in enterprise A is unable to route requests
directly to carrier B but is able to do so via an intermediate
carrier VSP, I. Enterprise A and carrier B each have some form of
agreement in place with carrier I, which allows them to route
requests to carrier I and receive requests from carrier I.
In this case peering between enterprise A and carrier B is achieved
through a combination of "peering" between enterprise A and carrier I
and peering between carrier I and carrier B.
+-----------------------+ +-------------+ +-----------------------+
| Enterprise A | | Carrier I | | Carrier B |
| +------+ +-------+ | | +-------+ | | +-------+ +------+ |
| | | | Proxy | | | | Proxy | | | | Proxy | | | |
| | UA A |----| A |-+---+--| I |--+---+-| B |----| UA B | |
| +------+ +-------+ | | +-------+ | | +-------+ +------+ |
+-----------------------+ +-------------+ +-----------------------+
4. Summary of peering relationship cases
The various use cases above showing direct and indirect peering
reveal the following peering relationships:
1. Enterprise-enterprise peering.
2. Enterprise-carrier peering.
3. Enterprise-enterprise peering (at least one of the enterprises
is a transit) as part of broader enterprise-enterprise peering.
4. Enterprise-carrier peering (the carrier is a transit) as part
of broader enterprise-enterprise or enterprise-carrier peering.
5. Carrier-carrier peering (at least one of the carriers is a
transit) as part of broader enterprise-enterprise or enterprise-
carrier peering.
Elwell & Rodrig Expires August 20, 2007 [Page 7]
Internet-Draft Enterprise peering February 2007
Cases 1 and 2 should be considered separately for the time being.
Analysis of technical requirements will reveal the similarities and
differences between these two cases.
It is not clear at present whether case 3 differs from case 1.
Similarly, it is not clear at present whether case 4 differs from
case 2. Further work should reveal whether there is any scope for
combining these cases.
Case 5 is probably the same as carrier-carrier peering in its own
right (i.e., with no enterprise involvement), in which case it would
fall outside the scope of this draft. However, analysis of technical
requirements will reveal whether or not this is true.
5. Discussion
5.1. Enterprise user identities
Enterprise user identities used between peers can be expressed in
different SIP/SIPS URI formats, including E.164-based URIs and non-
E.164-based URIs. Non-E.164-based URIs may or may not be able to be
mapped to/from E.164 numbers.
Enterprise-carrier peering, particularly for voice, will generally
require enterprise user identity URIs that can be mapped to/from
E.164 numbers (for direct reachability from PSTN). However, for
enterprise-enterprise peering (even if a transit carrier is involved)
it should be possible to use user identity URIs that do not map to
E.164 numbers, e.g. for IM and presence and even for voice.
A VSP should not need to be aware of which individual user identities
are valid within a peer's domain. For example, if domain example.com
has URIs of the form SIP:xxx@example.com, where xxx can be any value,
only example.com should be aware of which values of xxx are valid
(e.g., sip:12345@example.com,
sip:+12345678910@example.com;user=phone, sip:alice@example.com).
5.2. Routing
In order to route a SIP request to a peer, a VSP needs to know the
domain of the peer (e.g., example.com) and be able to obtain the
address of a ingress proxy in that domain or in some intermediate
domain that may be able to reach the target domain. For example,
when given a SIP URI such as sip:alice@example.com, a VSP just needs
to be able route directly or indirectly towards the example.com
domain. RFC 3263 [5] provides a means to do this. One of multiple
ingress proxies may be chosen depending, for example, on the location
Elwell & Rodrig Expires August 20, 2007 [Page 8]
Internet-Draft Enterprise peering February 2007
of the egress proxy. The target peer is then responsible for further
routing either within that domain (e.g., by loose routing or
retargeting) or by redirection.
When faced with just a telephone number (or TEL URI), a VSP will need
some means of looking up a domain that is responsible for the number
concerned, e.g., using ENUM (RFC 3761 [2]) or statically configured
routing tables. For enterprise peering, the granularity of this
look-up might not be down to the level of an individual number but on
the basis of prefixes. Different numbers or prefixes might map to
different sub-domains of the domain concerned or might map directly
to different ingress proxies in that domain.
5.3. Calling and connected identities
Calling and connected user identities are delivered to and from a
peer enterprise network during call establishment and at other times.
The enterprise can choose to use an individual user identity, an
enterprise main identity or some enterprise group identity e.g.
Enterprise A Sales, provided this is suitable for making a return or
repeat call. Anonymous identities will need to be used where privacy
is required.
An alternative would be to submit the true identity together with
an indication that it is subject to privacy, relying on the peer
not to disclose this information further. This might be necessary
in certain situations (e.g., emergency calls).
User identities sent to or from an enterprise peer network must have
some means to guarantee authenticity. This could be based either on
the P-Asserted-Identity header field (RFC 3325 [3]), with reliance on
transitive trust in indirect peering scenarios, or it could be a
cryptographically verifiable identity in the From header field
coupled with a signature in the Identity header field added by the
originating domain (RFC 4474 [4]).
5.4. User agent identities
SIP transports UA identities, for example in the Contact header
field. It is essential that these be globally routable. GRUU [9]
provides one way of assigning a globally routable identity to
entities that do not have globally routable IP addresses or host
names.
5.5. Signalling Security
Except in special situations where infrastructure is known to be
secured between peers, it is essential that signalling be secured.
Elwell & Rodrig Expires August 20, 2007 [Page 9]
Internet-Draft Enterprise peering February 2007
The standard SIP way of achieving this is by means of TLS, which
assumes that TCP is used as transport.
An alternative would be to use DTLS [6] with UDP. However,
message size considerations will prevent the use of UDP in many
circumstances.
Mutual authentication between adjacent peers is required. The peer
sending a request will need to verify that the request has been
received by and that the response comes from the expected domain.
Likewise, the peer that receives a request will need to verify that
the peer from which it is received is a domain from which it is
prepared to receive requests. TLS can provide this mutual
authentication based on certificates.
Some signalling information may need to be secured end-to-end.
Although the SIPS URI scheme provides a way of requesting that all
hops be secured by TLS, information is still exposed at SIP
intermediaries. Furthermore it does not provide a means of "best
effort" security, whereby UAs are informed whether a request is
secured on all hops or not. With these shortcomings in mind, S/MIME
bodies may be used to provide end-to-end encryption and/or integrity
protection and authentication. Furthermore, the Identity header
field, if used, provides integrity protection from the originating
domain as far as the UAS. Finally MIKEY [8], as one means of
performing key management for media security (see also [11]) provides
various forms of end-to-end protection for keying information.
Intermediate peers must provide transparency for information secured
in these ways.
5.6. Media and Media Security
Ideally media, particularly real-time media, should be sent directly
between the two endpoints (SIP UAs). In certain circumstances media
relays may be required to assist NAT traversal. In particular, for
indirect peering between enterprises, media would not necessarily be
routed through relays in the domain of intermediate peers, whose
function would be to assist in routing signalling and not media.
When exchanging IP addresses and ports for media reception, each peer
is responsible for supplying addresses and ports that are reachable
from the other peer. To achieve this, a peer may delegate this to
the endpoint, which can use well-known methods such as STUN and ICE
[10]. Manipulation of addresses and ports by SIP intermediaries for
NAT traversal purposes is also possible.
Media will need to be secured, e.g., using SRTP [7]. Key exchange
for this purpose will generally need to be agreed securely using
Elwell & Rodrig Expires August 20, 2007 [Page 10]
Internet-Draft Enterprise peering February 2007
signalling, thus placing end-to-end security requirements on this
aspect of signalling, as discussed in Section 5.5.
In-band and hybrid methods of key management for media security
are being discussed in the IETF (e.g., RTPSEC BoF at IETF 66).
These discussions may lead to alternative mechanisms, but current
standardised approaches use signalling to perform key management.
5.7. Transparency
When peering is indirect (e.g., peering between two enterprises via
intervening carrier or enterprise networks), it is important that an
adequate level of transparency is available. In particular, the
intervening peer must not modify or remove information beyond what is
necessary for the purpose of routing. For example, an intervening
peer should not:
o remove header fields and bodies that are intended for the
destination peer (whether or not they are understood);
o modify header fields and bodies in a way that will break any
integrity protection.
In addition, an intervening peer must not rely on information being
sent in the clear except where inspection is necessary to accomplish
routing.
For cases where a carrier or enterprise network intervenes between
two parts of the same enterprise, requirements for transporting
additional information transparently can be greater in order to cover
information specific to the enterprise. Such additional information
might relate to work groups, permissions, etc..
5.8. Regulatory aspects
Regulatory issues for enterprise peering are at present unclear, but
may have impact in some territories. Considerations may differ from
those impacting communication within a single enterprise on the one
hand and from those impacting carriers on the other hand.
One possible impact of regulation is support for lawful interception,
which may introduce some technical challenges in balancing the needs
of legitimate business communications against those of law
enforcement.
5.9. Management
Peer enterprise domains will need to be managed to provide
information needed to route outgoing requests, authorise incoming
requests and authenticate peers. Although information for routing
Elwell & Rodrig Expires August 20, 2007 [Page 11]
Internet-Draft Enterprise peering February 2007
might be available from public DNS, information might still need to
be provisioned to indicate the peer's policy for accepting incoming
requests (to avoid unnecessary attempts at sending requests that will
be blocked). For authentication, CA certificates will need to be
provisioned.
6. Conclusions
The discussion above does not necessarily identify significant
differences between enterprise peering and carrier peering. However,
examples of potential differences in detail are discussed in
Section 5.2 on routing and Section 5.8 on regulatory aspects. Thus
current SPEERMINT work could be extended to include enterprise
peering without significant impact. However, as investigations into
enterprise peering continue and as work in SPEERMINT proceeds, if
differences emerge, these would need to be taken into account.
7. IANA considerations
None.
8. Security considerations
Security aspects are discussed in Section 5.5, Section 5.6 and
Section 5.9 above.
9. Acknowledgements
The authors acknowledge assistance given by members of Ecma TC32-TG17
during the drafting of this document.
10. Informative References
[1] 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.
[2] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[3] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
Elwell & Rodrig Expires August 20, 2007 [Page 12]
Internet-Draft Enterprise peering February 2007
within Trusted Networks", RFC 3325, October 2005.
[4] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[7] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[8] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830,
August 2004.
[9] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-11 (work in progress),
October 2006.
[10] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in
progress), January 2007.
[11] Wing, D., Fried, S., and H. Tschofenig, "Media Security
Requirements", draft-wing-media-security-requirements-00 (work
in progress), October 2006.
[12] Sibley, C. and C. Gatch, "IP PBX / Service Provider
Interoperability", SIP Forum Recommendation-Draft sf-draft-twg-
IP_PBX_SP_Interop-sibley-sipconnect, March 2006.
Elwell & Rodrig Expires August 20, 2007 [Page 13]
Internet-Draft Enterprise peering February 2007
Authors' Addresses
John Elwell
Siemens Enterprise Communications Limited
Technology Drive
Beeston, Nottingham NG9 1LA
UK
Phone: +44 115 943 4989
Email: john.elwell@siemens.com
Benny Rodrig
Avaya
150 Apollo Drive
Chelmsford, MA 01824
USA
Phone: +1 978 677 5236
Email: brodrig@avaya.com
Elwell & Rodrig Expires August 20, 2007 [Page 14]
Internet-Draft Enterprise peering February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
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.
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Elwell & Rodrig Expires August 20, 2007 [Page 15]