Internet DRAFT - draft-aoun-midcom-intrarealmcalls
draft-aoun-midcom-intrarealmcalls
MIDCOM Working Group C.Aoun
Internet Draft S. Sen
Category: Informational Nortel Networks
Expires on July 2001 February 2002
Identifying intra-realm calls and
Avoiding media tromboning
<draft-aoun-midcom-intrarealmcalls-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This draft suggests several ways to identify calls initiated between
users within the same addressing realm. By having this capability,
media flows are kept within the same realm, thus avoiding usage of
certain network intermediaries and reducing bandwidth requirements
on certain access links.
Table of Contents
Status of this Memo ................................................1
Abstract ...........................................................1
1 Introduction .....................................................2
2 Conventions used in this document ................................3
3 Terminology Used .................................................3
4 Deployment scenarios .............................................3
4.1 Call scenarios .................................................4
4.2 Application requirements .......................................5
Internet Draft draft-aoun-midcom-intrarealmcalls-00.txt February 2002
5 Potential solutions to the problem ...............................6
5.1 Use domain name comparisons ....................................6
5.2 Use realm identifiers ..........................................6
5.3 Offer/Answer both private and public addresses .................7
6 Conclusion .......................................................8
7 References .......................................................8
8 Acknowledgments ..................................................9
9 Authors' Address .................................................9
10 Intellectual Property Statement .................................9
11 Full Copyright Statement ........................................9
1 Introduction
This draft suggests several ways way to identify if a call is being
initiated between users within the same realm. If this capability is
implemented, media flows are kept within the same addressing realm
whenever possible, thus avoiding usage of certain network
intermediaries and reducing bandwidth requirements on external links
into the realm.
Within the MIDCOM and pre-MIDCOM frameworks a solution must be found
to avoid calls established within the same realm using unnecessary
resources on the Middleboxes and on other devices such as Media
Proxies that could the pre-MIDCOM framework.
Within the MIDCOM framework, if there is no means to identify which
calls are intra-realm calls, all media flows will be routed to the
Middlebox applying the NAT function on the media flows and will need
to be looped back into the same realm at the Middlebox. Whether this
loop back behavior works correctly may depend on the Middlebox
implementation.
Within the pre-Midcom framework, if intra-realm calls are not
identified when reflector methods such as STUN ([STUN]) are used,
the Middlebox will need to loop back the flows. As discussed above
this requires a specific behavior of the Middlebox.
When Middleboxes have symmetric NAT implementations, Media Proxies
located outside the realm are used during the call and the media
flows will need to traverse the Middleboxes and the external links
to the realm. This is a serious waste of bandwidth on the
Middleboxes' external links which are often one of the major
bottlenecks in a network.
A generic model must be found by handling the source of the problem,
which is identifying intra-realm calls and then providing
appropriate address and port pairs to both parties in call that
avoid the media flows leaving the realm.
Several potential methods will be discussed in this draft. By
issuing this draft, the authors would like to start discussions on
Aoun Informational - Expires August 2002 [Page 2]
Internet Draft draft-aoun-midcom-intrarealmcalls-00.txt February 2002
solving this problem. The authors recognize that there might be
other alternatives to solve the problem.
Before proposing solutions to the problem, deployment scenarios need
to be considered.
Section 4 discusses network deployment cases.
Section 5 discusses potential solutions to the problem.
2 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
3 Terminology Used
MB: Middle Box - ref to the terminology used in [FRMWRK]
4 Deployment scenarios
++++++++++++++++++++++++++
+++++++++++++++++++ ++++++++++++++++ + y.com +
+finance.us.x.com + + + ++++++ +++++++++++
+ +++++ + + +----++MB6+ + tg1 +
+ fg1 +MB2+ +--/+ + ++++++ + is.y.com+
+ +++++ + / +The Internet + + +++++++++++
+ +++++ +/ + + +++++++++++++++ +
+ +MB1+ + + + +finance.y.com+ +
+ fg +++++ + + + + fg + +
+++++++++++++++++++ + + + + +
| ++++++++++++++++ ++++++++++++++++++++++++++
| / | |
| / | |
| ++++++++++++++++++ | |
| + +MB3+ + | |
| + +++++ + | |
| +eng.europe.x.com+ | |
| + tg1 + | |
| ++++++++++++++++++ | |
| | | |
+++++++++++++ +++++++++++++++++++++++++++++++++++++++++
+ x.com + + +MB4+ +MB5+ +
+ Intranet + + +++++ +++++ +
+ +-------+ Europe.x.com +++++++++++++++++++++++
+++++++++++++ + + finance.Europe.x.com+
+++++++++++++++++++ +
+eng.Europe.x.com++ fg +
+ ++++++++++++++++++++++++
+ tg2 tg3 + +
+++++++++++++++++++++++++++++++++++++++++
Aoun Informational - Expires August 2002 [Page 3]
Internet Draft draft-aoun-midcom-intrarealmcalls-00.txt February 2002
This section covers different network types, multi-homed networks
spanning several sites (with different registered address blocks) as
well as standard networks having one interconnect.
One assumption in this document is that inside a corporate network,
all private addresses are unique within the corporate's address
realm.
When corporations merge together, NAT will need to be used between
the private network segments during network migration.
4.1 Call scenarios
Since the document tries to provide solutions that will avoid intra-
realm calls going through the various MBs. These call scenarios need
to be used to check if the solution allows the required
functionality.
There are several intra-realm call types:
a1) Intra-name domain calls on same site or
a2) between different sites:
tg1.eng.europe.x.com calls tg2.eng.europe.x.com
or
tg2.eng.europe.x.com calls tg3.eng.europe.x.com
b1) Inter-name domain calls within same site (same public address
block)or
b2) different sites(different public address blocks):
tg2.eng.europe.x.com calls fg.finance.europe.x.com
or
tg1.eng.europe.x.com calls calls fg.finance.europe.x.com
Solutions need to be found to avoid the media streams from all
these call types going through MBs.
Registered address allocation might be important for the problem's
solution; the following two cases are considered:
Corporate networks could have a single main registered
address block provided by a regional (RIPE, ARIN, APNIC, etc)
Internet registry, which could be split across several sites.
Alternatively several non-contiguous registered blocks could
be provided by one or several Internet regional registries.
4.2 Application requirements
Certain applications may involve an entity handling the
application session control and another entity handling media
processing (i.e. a decoupled approach), other applications may
Aoun Informational - Expires August 2002 [Page 4]
Internet Draft draft-aoun-midcom-intrarealmcalls-00.txt February 2002
involve a single entity to host both roles (i.e. a coupled
approach).
In case the used solution to identify intra-realm calls uses the
address or the Fully Qualified Domain Name (FQDN) of the
application session control flow host, it may not solve the
problem for applications using the decoupled approach mentioned
above.
Aoun Informational - Expires August 2002 [Page 5]
Internet Draft draft-aoun-midcom-intrarealmcalls-00.txt February 2002
5 Potential solutions to the problem
5.1 Use domain name comparisons
Several applications' signaling protocols (H323, SIP, MEGACO or
MGCP) use FQDNs in their messages to identify the originator of the
signaling message.
When the "signaling proxy" (could be a SIP Proxy, an H323 GK in
routed mode or an MGC) receives the signaling messages from both
ends it will compare the domain names from the two messages. The
comparison will be done by comparing all characters following the
first "." in the FQDN.
The same could be done for peered relations between application
clients (i.e. the signaling does not go through an intermediary).
When tg1.eng.europe.x.com calls tg2.eng.europe.x.com, the result of
the comparison will show that both parties are in the same realm.
However when call types b1) or b2) are established, the comparison
will erroneously indicate that the parties to the call are not in
the same realm.
Accordingly this solution is not applicable to all network
deployments.
A further problem is that the protocols mentioned above do not
always use FQDNs to identify the application end points, which would
further limit this approach.
5.2 Use realm identifiers
A realm identifier could be used within the application signaling
messages to link the address provided with a certain realm.
Since users will be calling people from several different networks,
the realm identifier is required to be globally unique.
This might require that a single organization which would manage the
realm identifiers within the Internet, in the same way that
ICANN/IANA does for the root name servers.
This is a serious operational burden.
There are some possible alternative ways to provide a unique realm
identifier without the previous burden such as :
a) Registered network addresses as realm ID.
If a corporate has several non-contiguous address blocks, the
signaling proxy or the peer (if the signaling is not proxied) will
need to compare the network address prefix to all the others used by
Aoun Informational - Expires August 2002 [Page 6]
Internet Draft draft-aoun-midcom-intrarealmcalls-00.txt February 2002
the same company. If the network address does not match any of the
prefixes in the list of its company network addresses, the remote
end is assumed to be in another addressing realm.
b)In case a corporation (or customer) has a globally unique AS
number with a random customer number as a realm ID else the
customer's ISP AS number with a 32 bit customer identifier unique
within the customers of the ISP as the realm ID. Some corporation
have their own globally unique AS number, their realm ID will be
their AS number added to a random (or null) customer ID
If the customer network spans across several sites, the customer
network could be connected to several ISPs depending on the site
location.
In this case we consider that the customer or corporation will
choose one of its ISPs' AS number along with one of the assigned
customer Ids to the corporation, as the realm ID.
In both a) and b), it will be necessary to inform the customers'
application clients of the realm ID. We can assume that there are
some out of band mechanisms (configuration or otherwise) to achieve
this.
The authors acknowledges that there might be better approaches to
define a unique realm ID in the Internet without having the
operational burden raised above.
In addition, in order for this scheme to work, it requires that the
calling party sends both private and public addresses, because the
calling party is not aware of the called party's realm so a single
address/port pair won't help.
It is obvious that the realm ID approach requires extension to the
application signaling protocols, specifically for the media's
session description information carried as part of the protocols,
namely:
-H.245 for H.323
-SDP for SIP, Megaco and MGCP
-And other description means for other protocols
5.3 Offer/Answer both private and public addresses
Discovering intra-realm calls can be looked upon as a way to
discover the ideal media session for the call. Using the SDP
Offer/Answer model [OA], the initial Offer from the caller can
advertise two media sessions one with private IP address/port
(called private media session) and the other with public IP
address/port (called public media session). The Answer similarly
contains two corresponding media session descriptions accepting the
Offer. With this transaction, both the caller and the callee knows
about the media session representations of each other. In the next
Aoun Informational - Expires August 2002 [Page 7]
Internet Draft draft-aoun-midcom-intrarealmcalls-00.txt February 2002
step, the caller sends a simple probe message to the private media
session of the callee and starts a Timer. If the callee receives a
probe message, then it acknowledges it with a response to the
private media session address of the caller. This peer-to-peer probe
protocol is TBD, but it can be a derivate of any echo-server
protocol.
If the callee receives a probe message, then it must send an updated
Offer to the caller accepting the private media session and
rejecting the public media session. If the callee end-point decides
to send media after responding to the initial Offer (but before
receiving any probe message), it must always use the public IP
address/port. Once it has received a probe message and has not yet
started sending media, it should do so only after sending out the
updated Offer.
If the caller has sent out a probe message toward the callee, it
should not start sending media before the Timer expires or it
receives an updated Offer from the callee. In case the Timer
expires, it must send media to the public IP address/port only.
There is a possible scenario where the callee located in a different
address realm is using a private address that is being used in the
realm of the caller. Then the probe packet of the caller, intended
to be sent to the private address of the callee, will reach an
unintended destination in his own realm. But it would be extremely
difficult for this endpoint to hijack the session with a made-up
Offer, as it had not received the initial Offer.
Other security implications of this scheme is for further study.
6 Conclusion
The authors believe that there is some potential in the methods
discussed in 5.2 and 5.3 as solutions to identify intra-realm calls.
The authors invite the IETF community to start tackling the problem
and build a standard way to solve the issue.
7 References
[FRMWRK] Srisuresh, Kuthan, Rosenberg, Molitor, Rayhan,
"MIDCOM Architecture & Framework",
Internet draft, draft-ietf-midcom-framework-06.txt
[STUN] Rosenberg,Weinberger,Huitema,Mahy,
"STUN - Simple Traversal of UDP Through NATs",
Internet draft, draft-rosenberg-midcom-stun-00.txt
Aoun Informational - Expires August 2002 [Page 8]
Internet Draft draft-aoun-midcom-intrarealmcalls-00.txt February 2002
[OA] Rosenberg, Schulzrinne,
"An Offer/Answer Model with SDP",
Internet draft, draft-ietf-mmusic-sdp-offer-answer-01.txt
8 Acknowledgments
The authors would like to thank the following people for their
useful comments and suggestions related to this draft: Francois
Audet, Patrick Bradd, Elwyn Davies, Julian Mitchell and Moses Sun.
9 Authors' Address
Cedric Aoun
Nortel Networks
33 Quai Paul Doumer
92415 Courbevoie Cedex
FRANCE
Email: cedric.aoun@nortelnetworks.com
Sanjoy Sen
Nortel Networks
2735-C Glenville Drive
Richardson, Texas
USA
Email: sanjoy@nortelnetworks.com
10 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
11 Full Copyright Statement
Aoun Informational - Expires August 2002 [Page 9]
Internet Draft draft-aoun-midcom-intrarealmcalls-00.txt February 2002
Copyright (C) The Internet Society (2000). 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 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."
Aoun Informational - Expires August 2002 [Page 10]
