Internet DRAFT - draft-aoun-midcom-network


   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- 
   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 
   The list of Internet-Draft Shadow Directories can be accessed at 
   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 
   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 
   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 
   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",  
    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 
   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  
   (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  
          -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 
     +--------------+    +-----------+ 
     +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 
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 
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 
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 
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