Internet Engineering Task Force James M. Polk Internet Draft Cisco Systems Expiration:July 16th,Nov 19th, 2003 File:draft-polk-ieprep-flow-model-considerations-00.txtdraft-polk-ieprep-flow-model-considerations-01.txt Considerations for IEPREP Related Protocol Packet Flow ModelsJanuary 16th,May 19th, 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 asInternet-Drafts.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 discussingif (and which)which QoS mechanismsshouldcan be employed for each individual (application) protocol packet flow to function properly during congestion events from IP source to IPdestination. Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.0destination, as well as a potentially different QOS mechanism for a related but separate data flow (if present). 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .. . .2 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . .. . . . .2 1.2 Terms and Definitions . . . . . . . . . . . . . . . . . 3 1.3 Changes between document versions . . . . . . . . . . . . 32.02. Why Do Packet Paths Matter? . . . . . . . . . . . . . . . . .. . 3 3.04 3. Control and Data Plane Diagrams . . . . . . . . . . . . . . .. . 45 3.1 In-Band Point-to-Point Communications . . . . . . . . . .. . . . 45 3.2 In-Band Signaling Viaaan Intermediate Server . . . . . . 6 3.2.1 In-Band Signaling to a Composed Device . . . . . . . . 6 3.3 Out-of-Band Signaling . . . .5 3.3 Out-of-Band Signaling. . . . . . . . . . . . . . 7 3.3.1 Out-of-Band Signaling with one Control plane . . . . . 7 3.3.2 Out-of-Band Signaling with two Control planes . . . . .6 4.08 4. Security Considerations . . . . . . . . . . . . . . . . . . .. . 6 5.09 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . .6 6.0 Acknowledgements. . . . . . . . . . . . . . . . . . . . 9 7. References . . . .7 7.0 References. . . . . . . . . . . . . . . . . . . . . 9 8. Author Information . . . . . . .7 8.0 Authors Information. . . . . . . . . . . . . . 10 9. Full Copyright Statement . . . . . . . . .8 1.0. . . . . . . . . 10 1. 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 discussingif (and which)which QoS mechanismsshouldcan be employed for each individual (application) protocol packet flow to function properly during congestion events from IP source to IPdestination.destination, as well as a potentially different QOS mechanism for a related but separate data flow (if present). 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. 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 addressesisare different)2.01.3 Changes between document versions Here is the list of changes between internet draft versions -00 and -01: - named Figure 2 either a Triangle Model (with one server) or Trapezoidal Model (multiple servers) for further clarification - added Figure 4b to solve confusion surrounding categorization of FTP - added sections 3.3.1 and 3.3.2 to show that there can be more than one Out-of-Band Control plane - the above bullet resulted in the split up of Figure 5 into Figures 5a & 5b to solve the lack of categorization of MEGACO/H.248 and H.323 in which there are two Out-Of-Band Control planes for one data plane - changed the document formatting to be consistent with recent RFCs published - added comment in Abstract and Intro sections stating that due to the separation of paths for a communications type, different QOS mechanisms can be considered for each plane/path - removed the word "intermediate" from Figure 2 to relieve confusion 2. 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):IntermediateServer (one or more) / \ Out-of-Band / \ Out-of-Band Control plane A / \ Control plane B / Data plane \ ============================> Sender Receiver ++++++++++++++++++++++++++++> In-Band Control plane Figure 2. IP Communications usingIntermediate ServerServer(s) Figure 2 is called a Triangle Model when only one server is utilized by the sender and receiver. But when more than one server is used between endpoints, it is called a Trapezoidal Model. 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)B in Figure22) separately (such as with MEGACO/H.248[3] or H.323[4]). An additional aspect of this model in Figure 2aboveis that there will likely be more than oneintermediate(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 separatecommunicationscontrol planes, with up to 2 different packet paths for acommunicationsdata 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.03. Control and Data Plane Diagrams Figure 1 (above) showed the simplest of IP communication between source anddestination, but this model requiresdestination. However, Figure 1 assumes the sourceto knowdevice knows the IP address of thedestination, 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.destination device (which is not always the case). 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 paththoughthrough a network. Figure 3 below shows this in diagram form: The signaling flow model shown in Figure 3 only applies to those protocols that communicate from a source IP device (using one protocol port number) and another destination IP device (using the same protocol port number). --------> --------> --------> 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 Viaaan Intermediate Server A variation on the In-Band Model shown in Figure 3 (above) is the one in Figure44a 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 Figure44a 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 Figure4.4a. In-Band Signaling example Signaling protocol that uses this model for IP communications is: - SIP (when used for instant messaging[10]) The dataplanebetween the two endpoints generallyoccursis within the signaling packets as MIME bodies or text. 3.2.1 In-Band Signaling to a Composed Device In-Band signaling comes in two basic models: one with a decomposed or intermediate model (in which the destination IP device is separate physically and logically from the server) as just shown in Figure 4a, and a physically composed destination device (in which the server is same device as the data receiver, but logically separated) shown next in Figure 4b. In this model (Figure 4b), the communications is between the same two IP devices, but the signaling uses a different protocol port than that of the data packets between the two devices. +---------------+ | ___________ | | | | | ------>| | Server | | / | |___________| | -----> --------- | ___________ | Sender Router1 | | | | =====> ================>| | receiver | | | |___________| | | | +---------------+ Composed IP Device Legend: ----> In-Band Control plane (signaling) ====> Data (media/text/file) plane Figure 4b. In-Band Signaling example Protocol that uses this model for IP communications is: - FTP [11] A case could be made for POP3 and IMAP functioning under this model, with SMTP being the data plane; but it was decided that since SMTP was a different protocol (and not just port number) that these 3 protocols would be categorized in their native models. 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). Inthis example,the triangle model as shown in 3.3.1 Out-of-Band Signaling with one Control plane Figure 5a shows one type of the Triangle Model depicting a single Out-of-Band Control plane from Sender to Server to Receiver; 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 Figure5.5a. 'Single' Out-of-Band Signaling exampleProtocolsProtocol thatuseuses this model for IP communicationsare:is: - 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 endpointAside from minor incremented ortermination (see Figure 2 - control planes A & B).added/subtracted headers within the SIP message by the (Proxy) Server, the SIP message essentially arrives in tact at the UAS. As an example of the data plane in Figure55a above with SIP signaling, the data protocoliscould be RTP (either Voice or Video [1]).4.03.3.2 Out-of-Band Signaling with two Control planes Figure 5b shows the other Triangle Model for Out-of-Band Signaling in which there are multiple control planes (generally one each between the endpoints and the server). These different control planes are shown as (a) and (b) in Figure 5b. Each control plane will be unique to that endpoint from the server. Server/Controller ^ ^ (a) . . (b) <............ .............> Sender Router1 Router2 Receiver ========> ========> ========> Legend: ....> Out-of-Band Control plane (signaling) ====> Data (media/text/file) plane Figure 5b. 'Dual' Out-of-Band Signaling example Protocols that use this model for IP communications are: - MEGACO/H.248 [3] - H.323 (H.225/H.245) [4] with a Gatekeeper With both ITU-T protocols listed above, each uses unique control signaling - where signal 'a' is different than signal 'b' - between the endpoints and the server to facilitate the endpoints communicating. Similar to SIP in Figure 5a, MEGACO/H.248 and H.323 can use RTP in the data plane. 4. Security Considerations This documentmerely discussesis restricted to discussion of 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.5.05. IANA Considerations There are no IANA considerations within this document6.06. Acknowledgements To Scott Bradner, Kimberly King, Senthilkumar Ayyasamy and Henning Schulzrinne for their comments and suggestions7.07. 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 19858.08. Authors Information James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA jmpolk@cisco.com 9. Full Copyright Statement "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,Nov 19th, 2003