MIDCOM Working Group C.Aoun Internet Draft Nortel Networks Category: Informational June 2001 Expires on December 2001 Network topology considerations in the MIDCOM Architectural framework 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 In the present Internet architecture, packet transparency is lost due to the introduction of Middle Boxes that either modifies the contents of the IP packet, or drops it (Ref [RFC2775]). This draft presents in the context of the MIDCOM workgroup framework several Middle Boxes network deployment scenarios that needs to be considered. This draft assumes that the reader has sufficient knowledge on NAT (Ref [RFC2663]) and it's consequences (Ref [NAT-COMP]). This draft provides a list of topologies that needs to be considered (and their related implications) when deploying multimedia services over the Internet. It MUST not be seen as a protocol description document or an overall framework architecture document. Internet Draft Network Topologies scenarios June 2001 in the MIDCOM Framework Architecture Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Introduction.....................................................2 2 Conventions used in this document................................3 3 Network deployment scenarios.....................................3 3.1 Particular customer network configurations.....................4 3.2 The customer's ISP is the Content Service Provider.............5 3.3 The customer's ISP and the CSP are different legal entities....7 3.4 The Teleworker or small remote customer sites case.............7 4 Summary..........................................................8 5 References.......................................................8 6 Acknowledgments..................................................9 7 Author's Address.................................................9 8 Intellectual Property Statement..................................9 9 Full Copyright Statement.........................................9 1 Introduction The Middle Box (MB)terminology is aligned with the MIDCOM workgroup definition, i.e. a device that has router functionality and alters the content of either the IP header or it's content; or drops or forwards the packet depending on the filtering rule that is applied based on IP header/protocol type/transport port and this on packets coming from a certain group of users or interfaces. The MB terminology will probably evolve in time, the draft will be updated to take into account the new taxonomy. In order for the middle boxes to scale and have high performance, it is essential that the Middle boxes have no application awareness, which would require MBs to have at least a subset of the application's state machines. This approach requires that all traversed MBs have the required application awareness; this represents a major stopper to development of applications. Having the MB have application awareness is what is called having an Application Layer Gateway on the MB (Ref [RFC2663]). Application awareness is provided by devices already implicated in the application (case of In path agents), this device communicates with the MB to provide it the necessary information to allow the application to work. The MIDCOM protocol is the protocol used between the previous entities. The instance communicating with the Middle Box is the MIDCOM Agent (MA), the peer on that interface is the MIDCOM Interface on the Middle Box. Aoun Informational - Expires December 2001 [Page 2] Internet Draft Network Topologies scenarios June 2001 in the MIDCOM Framework Architecture The main reason for issuing this draft is to complement the current topologies taken into account within the MIDCOM framework (ref [MDCMFRWK]. Here is the main issue that this draft tries to get the MIDCOM WG to be concerned of: -How does the MIDCOM Agent know that the application's packets (either control stream or bearer stream) traverses MBs? Although this was decided to be out of scope of the MIDCOM WG, it is still a big piece of the puzzle. Manual provisioning of the encountered MBs and their applied functions on the MA will require a lot of effort (and probably won't scale). This issue should be tackled in the MIDCOM WG or elsewhere. This could prevent certain network topologies from being deployed. In the following, the 'Customer' network is a network containing a group of network elements (hosts, routers, servers, etc _)that is not in the Internet Service Provider network neither in the Content Service Provider network. 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 Network deployment scenarios This section handles several main network types: -The Content Service Provider (CSP)is the customer's Internet Service Provider (ISP). -The CSP is a separate provider from the customer's ISP. -The customer is in a remote site and is connected to it's enterprise VPN via a defined ISP. In all cases the customer network could be connected via an Access Network Provider which is separate from the ISP, this could happen for cable access and xDSL access. In the context of this document this is irrelevant considering that we are looking at the MB interaction problem. The traversed ISPs could have border MBs at their edges, or it could be assumed that no MBs will be encountered. The previous models are reflexive (i.e. the called parties have one of the previous network models), for clarity reasons the application pair (peers or Controlled) parties (i.e. calling and called parties, IP phone/Media Gateway _) are not shown. Aoun Informational - Expires December 2001 [Page 3] Internet Draft Network Topologies scenarios June 2001 in the MIDCOM Framework Architecture The CSP also has MBs that protect all the Content Service (voice per example) application devices (device controllers (i.e.MGCs), SIP Proxies, Element Management Systems (i.e. SNMP manager implementations), Media Gateways etc_) from the CSP internal network, the ISP network, the customers and the Internet. The following subsection provides a view on network topologies where several consecutive MBs are deployed to provide all the required MB services in the customer premise. 3.1 Particular customer network configurations The current market status shows that it is quite often to find several MBs in the customer network in the path of flows. These MBs could apply complementary MB functions to the packet flows that might traverse them. The figure below shows an example of a network topology where within a customer network 3 MBs are used : -MB1 provide secured access from the Internet and certain categories of users in the customer network; a packet filtering function is applied to the flow -MB2 applies packet filtering and NAT to the flow -MB3 applies QoS gating on per application's session basis -In the customer's ISP side MB4 applies QoS gating and packet diversion (in case law enforcement authorities require it) on per session basis. The QoS gating function allows reserving appropriate bandwidth for the application session. The reservation could also be accompanied with pre-emption on other existing flows of the same application (i.e. priority not defined on layer 2 or layer 3 priorities, but within the application). It is obvious that the order in which the Middle Box functions are applied is critical (especially for Nat and packet filtering)in this network type. ++++++++++++++++++++++++ +Appl Users+MB1+MB2+MB3+ ++++++++++++++++++++++++ + + +++++++++++ + +MB4+ + + ++++ + + ISP1 + +++++++++++ Currently it is not a lot frequent to find the likes of MB3 and MB4 in the network; but since the access interfaces (Customer <-> ISP Aoun Informational - Expires December 2001 [Page 4] Internet Draft Network Topologies scenarios June 2001 in the MIDCOM Framework Architecture network) will still be bandwidth limited for a while, QoS gates will be required on this interface to meet the applications' QoS requirements. This topology could be found in a lot of customer networks. The end to end network types follows in the next sections. 3.2 The customer's ISP is the Content Service Provider This type of network deployment is quite often in the context of delivering bundled data and voice services. There are 2 variants to this scenario: (1) The Middle Boxes (1 or many MBs) are managed by the customer network. (2) The MBs are managed by the service provider. In this model the MBs could be considered as trusted devices and are provided policy rules by a common policy server. This is what could be considered as complete carrier managed services. Type 1:This scenario could be subdivided into 2, case where the customer has 1 MB, whereas in the other case the customer have more than one MB. Typically several MBs are deployed in a customer's network when the customer has a VPN with widely spread sites, and the ISP provides several POIs to interconnect to the Internet. The case where several MBs could be traversed is quite interesting since it is almost impossible to know in advance which MB will be traversed (the traversal is based on the routing infrastructure and the destination application endpoint). +--------------+ +--------------+ +Customer A + +ISP & CSP + + +---+ + + + + +MB1+ + +--------------+ + +---+ + / + + + / + + +---+ + / + + +MBn+-----+-- + + +---+ + +-----------------+ +--------------+ +The Internet + +-----------------+ Aoun Informational - Expires December 2001 [Page 5] Internet Draft Network Topologies scenarios June 2001 in the MIDCOM Framework Architecture Type 2: Again this network model could be subdivided into several Models: -The customer has one Edge Router (ER) and only one MB is used in the ISP/CSP -The customer has n Edge Routers, and the ISP/CSP has only one interface on MB used for customer A -The customer has n ERs and the ISP/CSP has k MBs or k interfaces on the MBs dedicated for customer A Again there are issues on determining in advance which MBs will be traversed when several MBs are deployed. +--------------+ +--------------+ +Customer A + +ISP & CSP + + + + +---+ + + +---+ + + +MB1+ + + +ER1+ + + +---+ + + +---+ + /+ + + +---+ + / + +---+ + + +ERn+-----+-- + +MBk+ + + +---+ + + +---+ + +--------------+ + + +--------------+ + + +-----------------+ +The Internet + +-----------------+ Aoun Informational - Expires December 2001 [Page 6] Internet Draft Network Topologies scenarios June 2001 in the MIDCOM Framework Architecture 3.3 The customer's ISP and the CSP are different legal entities In these network types, the customer purchases the application services from a service provider different from its ISP. We shall assume that the customer's ISP is not directly connected to the application service provider, in case it is the model still applies. +--------------+ +-----------+ +Customer A + + ISP + + + + +---+ + + +---+ + + +MB1+ + +-----------------+ + +ER1+ + /+ +---+ + + CSP+----+ + + +---+ + / + + + +MB1x+ + + +---+ + / + +---+ + + +----+ + + +ERn+-----+/ + +MBk+ + + +----+ + + +---+ + + +---+ + /+ +MBmx+ + +--------------+ + + / + +----+ + +-----------+ / +-----------------+ + / + / +-----------------+ +The Internet + +-----------------+ In this network model, the MBs could also be in the Customers premise, i.e. both type 1 and type 2 network types apply to these networks. 3.4 The Teleworker or small remote customer sites case +--------------+ +-----------+ +Customer A + + ISP + + + + +---+ + + +---+ + + +MB1+ + +--------------+ + +ER1+-----+ + +---+ + + CSP+----+ + + +---+ + + + + +MB1x+ + + + + + + +----+ + + +---+ + + +----+ + + + + +ERn+-----+--- + +MBk + + + +----+ + + +---+ + + +----+ + / + +MBmx+ + +--------------+ + + / + +----+ + +-----------+ / +--------------+ + / +-----------+ + / +Teleworker/+ + / +remote site+ +-----------------+ / + +----+ + +The Internet +--/--------+ +MB1h+ + +-----------------+ + +----+ + +-----------+ Aoun Informational - Expires December 2001 [Page 7] Internet Draft Network Topologies scenarios June 2001 in the MIDCOM Framework Architecture This network model has several variants that could be inherited from 2.1 and 2.2. This model is not completely different from the previous ones, from a VoIP perspective since the application (VoIP) is provided through the customer's VPN. Hence the Teleworker/remote site, establishes a tunnel (IPSEC ESP per example, other IP tunneling protocols could be used as well)for all the traffic related to the customer A VPN. All the tunneled information will not be altered, therefore there is no different constraints/interaction with the MBs (from a VoIP perspective) from 2.1 and 2.2. 4 Summary The network topologies in the previous sections show new deployment considerations, where the MA will need to negotiate network parameters with : - Various Middle Boxes with different MB functions - Different Middle Boxes for the application signaling protocol than for the media packets [MDCMFRWK] does not take into account topologies where the bearer path is traversing either a different interface then the application protocol messages or even a different MB. The ideal is to define a model that meets carrier managed network type (i.e. Type 2 networks, with the service provider providing the Middle Box services) as well as type 1 networks (where the Middle Boxes are managed by the customer, and most likely this customer has few, probably 1 MB). Initiatives need to be actively started within the IETF either in the MIDCOM WG or in another WG, to start looking at MBs discovery. There are two approaches to this, either build a mechanism around MB discovery specifically or around "special" network elements discovery to take into account various "special type" network nodes. Obviously the later approach should never be handled in the MIDCOM WG. 5 References [RFC2663] P.Srisuresh, M. Holdrege, "IP Network Address Translator(NAT)Terminology and Considerations", RFC 2663 August 1999. [NAT-COMP]P.Srisuresh, M. Holdrege, " Protocol Complications with the IP Network Address Translator", RFC 3027 Jan 2001 [MDCMFRWK]P.Srisuresh,J.Kuthan, J.Rosenberg," MIDCOM Architecture & Framework", Internet draft, draft-ietf-midcom-framework-01.txt Aoun Informational - Expires December 2001 [Page 8] Internet Draft Network Topologies scenarios June 2001 in the MIDCOM Framework Architecture [RFC2775] B. Carpenter, Internet Transparency 6 Acknowledgments The author would like to thank the following people for their useful comments and suggestions related to this draft: Patrick Bradd, Matt Broda, Louis-Nicolas Hamer, Mick O'Doherty, Reynaldo Penno, Abdallah Rayhan, Massimo Strazzeri and many others in Nortel Networks. 7 Author's Address Cedric Aoun Nortel Networks 33 Quai Paul Doumer 92415 Courbevoie Cedex FRANCE Email: cedric.aoun@nortelnetworks.com 8 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. 9 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 Aoun Informational - Expires December 2001 [Page 9] Internet Draft Network Topologies scenarios June 2001 in the MIDCOM Framework Architecture 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."