Internet DRAFT - draft-polk-ieprep-flow-model-considerations
draft-polk-ieprep-flow-model-considerations
Internet Engineering Task Force James M. Polk
Internet Draft Cisco Systems
Expiration: Nov 19th, 2003
File: draft-polk-ieprep-flow-model-considerations-01.txt
Considerations for IEPREP Related
Protocol Packet Flow Models
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 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
which QoS mechanisms can be employed for each individual
(application) protocol packet flow to function properly during
congestion events from IP source to IP destination, as well as a
potentially different QOS mechanism for a related but separate data
flow (if present).
Polk IEPREP Protocol Packet Flow Considerations [Page 1]
Internet Draft May 19th, 2003
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Terms and Definitions . . . . . . . . . . . . . . . . . 3
1.3 Changes between document versions . . . . . . . . . . . . 3
2. Why Do Packet Paths Matter? . . . . . . . . . . . . . . . . . 4
3. Control and Data Plane Diagrams . . . . . . . . . . . . . . . 5
3.1 In-Band Point-to-Point Communications . . . . . . . . . . 5
3.2 In-Band Signaling Via an Intermediate Server . . . . . . 6
3.2.1 In-Band Signaling to a Composed Device . . . . . . . . 6
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 . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Author Information . . . . . . . . . . . . . . . . . . . . . 10
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . 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
discussing which QoS mechanisms can be employed for each individual
(application) protocol packet flow to function properly during
congestion events from IP source to IP 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.
Polk IEPREP Protocol Packet Flow Considerations [Page 2]
Internet Draft May 19th, 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
are different)
1.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
Polk IEPREP Protocol Packet Flow Considerations [Page 3]
Internet Draft May 19th, 2003
- 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):
Server (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 using Server(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 in Figure 2) separately (such as with MEGACO/H.248[3] or
H.323[4]).
An additional aspect of this model in Figure 2 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;
Polk IEPREP Protocol Packet Flow Considerations [Page 4]
Internet Draft May 19th, 2003
sometimes there might be several servers between the source and
destination domains.
Because there can be up to 3 separate control planes, with up to 2
different packet paths for a data 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, but attempts to include those that are of interest
to the IEPREP effort.
3. Control and Data Plane Diagrams
Figure 1 (above) showed the simplest of IP communication between
source and destination. However, Figure 1 assumes the source device
knows the IP address of the 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 path through
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]
Polk IEPREP Protocol Packet Flow Considerations [Page 5]
Internet Draft May 19th, 2003
- 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 an Intermediate Server
A variation on the In-Band Model shown in Figure 3 (above) is the
one in Figure 4a 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 4a 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 4a. In-Band Signaling example
Signaling protocol that uses this model for IP communications is:
- SIP (when used for instant messaging[10])
The data between the two endpoints generally is 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.
Polk IEPREP Protocol Packet Flow Considerations [Page 6]
Internet Draft May 19th, 2003
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). In 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.
Polk IEPREP Protocol Packet Flow Considerations [Page 7]
Internet Draft May 19th, 2003
Intermediary Server
^ .
. .
............. .............>
Sender Router1 Router2 Receiver
========> ========> ========>
Legend: ....> Out-of-Band Control plane (signaling)
====> Data (media/text/file) plane
Figure 5a. 'Single' Out-of-Band Signaling example
Protocol that uses this model for IP communications is:
- SIP (for Voice and Video when the UAC does not know the IP
address of the UAS, thus requiring a Proxy Server [6])
Aside from minor incremented or 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 Figure 5a above with SIP
signaling, the data protocol could be RTP (either Voice or Video
[1]).
3.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
Polk IEPREP Protocol Packet Flow Considerations [Page 8]
Internet Draft May 19th, 2003
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 document is 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. IANA Considerations
There are no IANA considerations within this document
6. Acknowledgements
To Scott Bradner, Kimberly King, Senthilkumar Ayyasamy and Henning
Schulzrinne for their comments and suggestions
7. 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
Polk IEPREP Protocol Packet Flow Considerations [Page 9]
Internet Draft May 19th, 2003
[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
8. 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.
Polk IEPREP Protocol Packet Flow Considerations [Page 10]
Internet Draft May 19th, 2003
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:
Nov 19th, 2003
Polk IEPREP Protocol Packet Flow Considerations [Page 11]
