MIDCOM Working Group C.Aoun Internet Draft Nortel Networks Category: Informational November 2001 Expires on May 2001 Potential Solutions to the Middle Box discovery problem 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 The Middle Box discovery is one of the problems that the Midcom architecture has not yet solved. This document proposes a high level view of potential solutions to the problem as well as interactions with the Midcom architecture. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Introduction.....................................................2 2 Conventions used in this document................................2 3 Used Terminology.................................................2 4 Discovery concepts...............................................3 4.1 Stimuli to send discovery messages.............................4 4.2 Sending the resulting discovery messages.......................5 Internet Draft draft-aoun-midcom-discovery-00.txt November 2001 4.3 Middle Box Discovery Message Sequence..........................5 5 Load Share and reliability issues................................5 5.1 Countering Equal Cost Multi-path issues........................5 5.2 Middle Box fail-over issues....................................5 6 Interaction with the Midcom architecture and issues..............5 7 Security considerations..........................................6 8 References.......................................................6 9 Author's Address.................................................6 10 Intellectual Property Statement.................................6 11 Full Copyright Statement........................................7 1 Introduction Most of the Middle Box discovery requirements has already been documented in [Elear]. Several deployment scenarios are documented in [Caoun]. In this draft proposals will be provided to meet the requirements as well as other issues that still needs to be solved. Middle box discovery should take into account peer to peer applications as well as in the cases where application signaling goes through application proxies or "application controllers" (ref to the H323 architecture, SIP when SIP proxies are used and the Megaco architecture, or other applications where application signaling proxies are used). The Middle Box (MB)terminology is aligned with the MIDCOM workgroup definition. The MB terminology will probably evolve in time, the draft will be updated to take into account the new taxonomy. 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 Used Terminology MB: Middle Box- ref to the used terminology in [FRMWRK] MA: Midcom Agent - ref to the used terminology in [FRMWRK] MS: Midcom Server- The Midcom interface on the MB, terminology not yet defined within the Midcom WG Aoun Informational - Expires May 2002 [Page 2] Internet Draft draft-aoun-midcom-discovery-00.txt November 2001 AC: Application Client AS: Application Server- In this document the used terminology covers the application server function as well as it's host. DA: Discovery agent- An entity that receives MB discovery results and forwards it to the required MA. The DA is also responsible for stimulating the Application Clients to send discovery messages when applicable DC: Discovery Client - Entity responsible for sending/receiving discovery messages DN: Discovery Node - Function that sits in a Middle Box, updates a discovery message. In some cases it may terminate and loop back the discovery messages AH: Application Host- Computing platform hosting an application entity 4 Discovery concepts The MB discovery is based on the following: -a) The application client will send a discovery message towards the end application party. -b) Each traversed MB will modify the discovery message and provide the actions that are applied to the packet flows. -c) The destination application party will loop back the discovery message to the application client -d)b) is applied again -f) The application client will then send the discovery message to the authorized Midcom agents There are some prerequisites for the solution: -What is the stimulus for the application client to send the discovery message? -To which Midcom agents the resulting discovery message will be sent ? The traversed MBs may not be controlled by the same Midcom agents. Aoun Informational - Expires May 2002 [Page 3] Internet Draft draft-aoun-midcom-discovery-00.txt November 2001 ++++++++++++++++++++++++++ + +++++ + + +AC + + +++++++++++++++++++++ + +---+ +++++++ + +++++++++++ +Application Service+ + +DC + +DN MS+-+---+ Internet+-------+Provider + + +++++ +++++++ + + + + + + AH1 MB1 + /+++++++++++ + +++++++ + + + / | + +MA-DA+ + + +/ | + +++++++ + + +++++++ + | + AS1 + + +DN-MS+/+ | + + + +++++++ + | +++++++++++++++++++++ + MB2 + | ++++++++++++++++++++++++++ | | ++++++++++++++++++++++++++++++++++ + + + +++++++ +++++++ +++++++ + + +DN-MS+ +DN-MS+ +MA-DA+ + + +++++++ +++++++ +++++++ + + MB3 MB4 AS2 + + + + +++++ + + +AC + + + +---+ + + +DC + + + +++++ + + AH2 + + + ++++++++++++++++++++++++++++++++++ Figure 1 4.1 Stimuli to send discovery messages -a) The application controller requests the application client to send the discovery message -b) The application client sends the discovery message implicitly to all application parties or a group of them The first option could be interesting in case caching capabilities are provided at the application controller. Aoun Informational - Expires May 2002 [Page 4] Internet Draft draft-aoun-midcom-discovery-00.txt November 2001 When caching capabilities are available, the application controller saves for a period of time the source and destination of application flows and the associated traversed MB. An intelligent aggregation scheme could be used either network based or domain based. Only destinations that were not already reached will require the application client to send a discovery message. The second option requires no interaction between the application controller and the application client, and fits also applications that doesn't natively use proxies. It could be realistic to consider cases where caching capabilities exist on the application client in that case a caching period is used, thus avoiding useless discovery messages to be sent. 4.2 Sending the resulting discovery messages Once the discovery result reaches the application client, the application client has to send it to the adequate Midcom agent who will need to control the required MBs. As shown in Figure 1 there maybe 2 (or potentially more) MAs that will need to control the MBs in order to allow the application to be successful. In case the stimulus to send the discovery message is based on an interaction between the Application Server (or Controller), the application server will provide via the co-hosted DA (per eg:DA1 in AS1) , the DAs (DA2 in figure 1) to be notified of the MB discovery result. This requires certain means of communicating the address and port on which the DAs could be reached especially DA2 in figure 1. These means of communication could potentially be an envelop parameter in the application layer though some extensions(SIP or as SDP extensions, H225 or H245 or other protocols depending on the used application). 4.3 Middle Box Discovery Message Sequence To be documented 5 Load Share and reliability issues To be documented 5.1 Countering Equal Cost Multi-path issues To be documented 5.2 Middle Box fail-over issues To be documented 6 Interaction with the Midcom architecture and issues To be documented Aoun Informational - Expires May 2002 [Page 5] Internet Draft draft-aoun-midcom-discovery-00.txt November 2001 7 Security considerations To be documented 8 References [Caoun] C.Aoun, "Network topology considerations in the MIDCOM Architectural framework", Internet draft, draft-aoun-midcom-network-00.txt [FRMWRK] P.Srisuresh,J.Kuthan, J.Rosenberg," MIDCOM Architecture & Framework", Internet draft, draft-ietf-midcom-framework-05.txt [Elear] E. Lear, "Requirements for Discovering Middleboxes", Internet draft, draft-lear-middlebox-discovery- requirements-00.txt 9 Author's Address Cedric Aoun Nortel Networks 33 Quai Paul Doumer 92415 Courbevoie Cedex FRANCE Email: cedric.aoun@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 Aoun Informational - Expires May 2002 [Page 6] Internet Draft draft-aoun-midcom-discovery-00.txt November 2001 Director. 11 Full Copyright Statement 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 May 2002 [Page 7]