[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

         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]
      

Html markup produced by rfcmarkup 1.128b, available from https://tools.ietf.org/tools/rfcmarkup/