Internet Engineering Task Force James M. Polk Internet Draft Cisco Systems Expiration: July 16th, 2003 File: draft-polk-ieprep-flow-model-considerations-00.txt Considerations for IEPREP Related Protocol Packet Flow Models January 16th, 2003 Status of this Document 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 document diagrams the packet flows - both signaling and data - of Internet Emergency Preparedness (IEPREP) related protocols. This document serves as a point of reference for the WG when discussing if (and which) QoS mechanisms should be employed for each individual (application) protocol packet flow to function properly during congestion events from IP source to IP destination. Polk IEPREP Protocol Packet Flow Considerations Page 1 Internet Draft Jan 16th, 2003 Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.0 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Terms and Definitions . . . . . . . . . . . . . . . . . . . . . . 3 2.0 Why Do Packet Paths Matter? . . . . . . . . . . . . . . . . . . . 3 3.0 Control and Data Plane Diagrams . . . . . . . . . . . . . . . . . 4 3.1 In-Band Point-to-Point Communications . . . . . . . . . . . . . . 4 3.2 In-Band Signaling Via a Server . . . . . . . . . . . . . . . . . . 5 3.3 Out-of-Band Signaling . . . . . . . . . . . . . . . . . . . . . . 6 4.0 Security Considerations . . . . . . . . . . . . . . . . . . . . . 6 5.0 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 6 6.0 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 7.0 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.0 Authors Information . . . . . . . . . . . . . . . . . . . . . . . 8 1.0 Introduction This document diagrams the packet flows - both signaling and data - of Internet Emergency Preparedness (IEPREP) related protocols. This document should be seen as a point of reference for the WG when discussing if (and which) QoS mechanisms should be employed for each individual (application) protocol packet flow to function properly during congestion events from IP source to IP destination. The models shown within the document will focus (and list) those protocols of interest to the Internet Emergency Preparedness (IEPREP) Working Group. Of particular interest here is the classification of protocols that have their signaling packets travel along the same path as the data packets, and which protocols do not share the data path with their signaling packets. This document will focus on the concept that in most IETF protocols there are one or two control planes and one data plane. 1.1 Motivation This document clarifies paths taken by signaling and data packets for typical IETF protocols. These concepts will help facilitate IEPREP discussions on ensuring applications perform adequately during congestive events. Polk IEPREP Protocol Packet Flow Considerations Page 2 Internet Draft Jan 16th, 2003 1.2 Terms and Definitions The following are pointed out for clarity: Control Plane - See "In-Band Signaling" and "Out-of-Band Signaling" Data Plane - the data packet (media, text, MIME body) path between an IP source and one or more endpoints Intermediary Server - Any server that is the destination of control information from the IP source. These packets can either be for the server itself, or for further forwarding toward the intended destination possibly manipulating the packet(s) in transit In-Band Signaling - the control plane packets traversing the same path as the data plane between endpoints (same source IP address and port number, as well as the same destination IP address and port number) Out-of-Band Signaling - the control plane taking a different path than the data path or the In-Band control plane (either the source and destination IP addresses are different between the control packets and data packets, or the port numbers used between the same source and destination IP addresses is different) 2.0 Why Do Packet Paths Matter? Most IETF communications use the following simple model: Sender ========> Router(s) ========> Receiver Figure 1. Direct IP Communications But many IP communications use this model (or a variant of it): Intermediate Server / \ Out-of-Band / \ Out-of-Band Control plane A / \ Control plane B / Data plane \ ============================> Sender Receiver ++++++++++++++++++++++++++++> In-Band Control plane Figure 2. IP Communications using Intermediate Server Polk IEPREP Protocol Packet Flow Considerations Page 3 Internet Draft Jan 16th, 2003 The data plane can be within the signaling protocol (in the case of Instant Messaging), or it can be a completely different protocol (i.e. RTP for Voice or Video [1] or SMTP [2]). In some cases, there is no In-Band control plane. In other cases, there is no out-of-band control plane. Some protocols use both Out-of-Band control planes (A & B) in Figure 2 separately (such as with MEGACO/H.248[3] or H.323[4]). An additional aspect of this model in Figure 2 above is that there will likely be more than one intermediate server involved in most protocols that communicate through any intermediate server. Most likely there is one in the source IP device's domain, and there is also one in the destination IP device's domain. There may or may not be any intermediate servers in the ISP(s) between these two domains; sometimes there might be several servers between the source and destination domains. Because there can be up to 3 separate communications planes, with up to 2 different packet paths for a communications transfer, it is important to understand which protocols transmit their packets on which path. The rest of this document will provide these various packet path models for IEPREP related protocols. Keep in mind that the "Receiver" in many of these diagrams is either (or both) a server and/or a user device. Also note that this document doesn't cover an exhaustive IETF protocols list, each categorized, but attempts to include those that are of interest to the IEPREP effort. 3.0 Control and Data Plane Diagrams Figure 1 (above) showed the simplest of IP communication between source and destination, but this model requires the source to know the IP address of the destination, for that source to use a protocol that requires no intermediate servers, and that protocol to have all necessary signaling and data traverse point to point. 3.1 In-Band Point-to-Point Communications This model is true only if the communication is as in the previous paragraph: one protocol (with one port number) and one path though a network. Figure 3 below shows this in diagram form: Polk IEPREP Protocol Packet Flow Considerations Page 4 Internet Draft Jan 16th, 2003 --------> --------> --------> Sender Router1 Router2 Receiver ========> ========> ========> Legend: ----> In-Band Control plane (signaling) ====> Data plane (media/text/file) Figure 3. In-Band Signaling example Protocols that use this model for IP communications are: - H.323 (without a Gatekeeper only)[4] - Telnet [5] - SIP (when the UAC knows the IP address of the UAS)[6] - HTTP [7] - POP3 [8] - IMAP [9] The data plane in these protocols is set-up by the signaling (control) plane between endpoints. 3.2 In-Band Signaling Via a Server A variation on the In-Band Model shown in Figure 3 (above) is the one in Figure 4 in which all communications traverse an Intermediate Server(s). Here the signaling and data are contained with the same protocol that hops through a server(s) on its path towards the destination IP device. In Figure 4 below, the placement of one or more routers doesn't directly affect the path of the packets between the Sender to the Server and on to the Receiver, therefore none are shown here to make the diagram cleaner. --------------> -------------> Sender Intermediary Server Receiver ==============> =============> Legend: ----> In-Band Control plane (signaling) ====> Data (media/text/file) plane Figure 4. In-Band Signaling example Signaling protocol that uses this model for IP communications is: - SIP (when used for instant messaging[10]) Polk IEPREP Protocol Packet Flow Considerations Page 5 Internet Draft Jan 16th, 2003 The data plane generally occurs within the signaling packets as MIME bodies or text. 3.3 Out-of-Band Signaling Out-of-Band control is the case where a signaling protocol (likely) establishes the data plane via some intermediate server or servers (see Figure 5). In this example, the data packets are not transmitted to or through the server (towards the ultimate receiver). The signaling path from the sender to the server is not the same path as the data plane from the sender to the receiver (which is direct in this example). Here each path could be considered for different treatment and handling. Intermediary Server ^ . . . ............. .............> Sender Router1 Router2 Receiver ========> ========> ========> Legend: ....> Out-of-Band Control plane (signaling) ====> Data (media/text/file) plane Figure 5. Out-of-Band Signaling example Protocols that use this model for IP communications are: - SIP (for Voice and Video when the UAC does not know the IP address of the UAS, thus requiring a Proxy Server [6]) - FTP [11] H.323 [4] and MEGACO/H.248 [3] are not categorized here because these protocols use two independent control planes between the Gatekeeper or Media Gateway Controller and each endpoint or termination (see Figure 2 - control planes A & B). As an example of the data plane in Figure 5 above with SIP signaling, the data protocol is RTP (either Voice or Video [1]). 4.0 Security Considerations This document merely discusses the modeling differences of various IETF protocols which control the communications signal between a source and (one or more) destination(s), therefore there are no special security considerations. Polk IEPREP Protocol Packet Flow Considerations Page 6 Internet Draft Jan 16th, 2003 5.0 IANA Considerations There are no IANA considerations within this document 6.0 Acknowledgements To Scott Bradner, Kimberly King, and Henning Schulzrinne for their comments and suggestions 7.0 References [1] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ôRTP: A Transport Protocol for Real-Time Applicationsö, RFC 1889, January 1996 [2] J. Klensin, "Simple Mail Transfer Protocol, RFC 2821, April 2001 [3] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers, ôMegaco Protocol Version 1.0ö, RFC 3015, November 2000. [4] ITU-T H.323v2 Recommendation, "Packet-Based Multimedia Communications System", 1996 [5] J. Postel, J. Reynolds, "Telnet Protocol Specification", RFC 854, May 1983 [6] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [7] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., Masinter, P. Leach, T. Berners-Lee, " Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999 [8] J. Myers, M. Rose, "Post Office Protocol - version 3", RFC 1939, May 1996 [9] M. Crispin, "Internet Message Access Protocol - Version 4 rev1", RFC 2060, Dec 1996 [10] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, " Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002 [11] J. Postel, J. Reynolds, "File Transfer Protocol", RFC 959, Oct 1985 Polk IEPREP Protocol Packet Flow Considerations Page 7 Internet Draft Jan 16th, 2003 8.0 Authors Information James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA jmpolk@cisco.com "Copyright (C) The Internet Society (2002). 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." The Expiration date for this Internet Draft is: July 16th, 2003 Polk IEPREP Protocol Packet Flow Considerations Page 8