Network Working Group P. Francis
Internet-Draft S. Guha
Intended status: Standards Track Cornell U.
Expires: October 22, 2007 S. Brim
M. Shore
Cisco
April 20, 2007
An EME Signaling Protocol Design
draft-irtf-eme-francis-nutss-design-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on October 22, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Francis, et al. Expires October 22, 2007 [Page 1]
Internet-Draft An EME Signaling Protocol Design April 2007
Abstract
This document presents a high-level design for an End-Middle-End
(EME) signaling protocol called NUTSS (which stands for NAT, URI,
Tunnel, Signaling, STUN). While high-level, this document tries to
be detailed enough that the EME RG can have a meaningful debate about
its pros and cons and possible alternatives. The main attribute of
NUTSS is that it couples together both path-coupled and path-
decoupled signaling.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Relationship with existing signaling protocols . . . . . . 3
2. Dual Signaling Overview . . . . . . . . . . . . . . . . . . . 4
2.1. Terms and Components . . . . . . . . . . . . . . . . . . . 4
2.2. Name-routing between P-boxes . . . . . . . . . . . . . . . 5
2.3. Relationship between P-boxes and associated M-boxes . . . 6
2.4. High-level approach to dual signaling . . . . . . . . . . 7
3. Signaling Details . . . . . . . . . . . . . . . . . . . . . . 9
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Case A . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. Comments . . . . . . . . . . . . . . . . . . . . . . . 14
4.2. Case B . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Case B, Version a . . . . . . . . . . . . . . . . . . 16
4.2.2. Case B, Version b . . . . . . . . . . . . . . . . . . 18
4.2.3. Case B, Version c . . . . . . . . . . . . . . . . . . 19
4.2.4. Case B, Version d . . . . . . . . . . . . . . . . . . 20
4.2.5. Case B, Version e . . . . . . . . . . . . . . . . . . 23
5. Case C . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. Case D . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Case D, Version a . . . . . . . . . . . . . . . . . . . . 27
6.2. Case D, Version b . . . . . . . . . . . . . . . . . . . . 31
7. Security Considerations . . . . . . . . . . . . . . . . . . . 34
8. Normative References . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
Francis, et al. Expires October 22, 2007 [Page 2]
Internet-Draft An EME Signaling Protocol Design April 2007
1. Introduction
This document presents a high-level design for an End-Middle-End
(EME) signaling protocol that satisfies the requirements in
[I-D.guha-emerg-requirements]. This document tries to be detailed
enough that the EME RG can have a meaningful debate about its pros
and cons and possible alternatives. Clearly, however, much detail is
missing and still needs to be filled in. The intent is that this
detail can be created once the EME RG builds consensus on a high-
level approach.
The core idea behind NUTSS is that it exploits both path-decoupled
and path-coupled signaling, coordinating them in such a way that the
limitations of either individual approach are overcome.
Specifically, path-decoupled signaling is able to provide
authorization tokens that are then handed to middleboxes through
path-coupled signaling. Middleboxes, in turn, are able to refer
endpoints to path-decoupled signaling devices so that they may obtain
the appropriate tokens.
Despite our best efforts to the contrary, this version (0) is likely
to have numerous errors, especially in the examples. We appreciate
comments on these so that we can put out a cleaner version soon.
1.1. Relationship with existing signaling protocols
Obviously there is tons of existing work that relates to this,
especially SIP, NSIS, and RSVP. This section needs to be filled in,
but for now we'll let it suffice to say that the dual-signaling
approach described in this paper could heavily borrow specific
mechanisms from these "uni-signaling" approaches. This is for
further study.
Francis, et al. Expires October 22, 2007 [Page 3]
Internet-Draft An EME Signaling Protocol Design April 2007
2. Dual Signaling Overview
2.1. Terms and Components
This paper uses the terms "name-routed" and "address-routed" to refer
to the two forms of signaling used by NUTSS. We define name-routed
signaling as signaling that uses a name (URI) to route the signaling
message. We define address-routed signaling as signaling that uses
the IP address(es) that are ultimately used by data packets to route
the signaling. Address-routed signaling can be out-of-band (i.e.
message-based), or in-band (embedded in the data flow itself).
Name-routed signaling is needed, at a minimum, to obtain one or more
IP addresses that can be used to reach the destination host (or
middleboxes along the way). There are other uses for name-routed
signaling as well. Name-routed signaling allows protocols to be
negotiated (network layer, transport layer, security), and allows
flexible deployment of where policy decisions are made (i.e.
replication of policy boxes). Clearly name-routed signaling is
valuable, and SIP is a testament to this.
Address-routed signaling is needed because ultimately it is boxes on
the data path (i.e. firewalls) that enforce policy.
Given that we require both name- and address-routed signaling (aka
"dual signaling"), there must be some way to coordinate the two.
Before describing this, we first define the components of NUTSS.
There are two components in NUTSS, policy boxes (p-box), and
middleboxes (m-box). P-boxes handle name-routed signaling messages.
That is, a name-routed message travels between end-hosts from p-box
to p-box. The end-point name (a URI) to which the signaling message
is being delivered is used to determine what the next p-box on the
path should be. P-boxes tend to make "policy" decisions, such as
whether a flow is allowed, what data protocols will be used for the
flow, and so on.
M-boxes handle address-routed signaling messages as well as data
packets (which, by definition are address-routed). Sometimes m-boxes
receive address-routed messages that are not addressed to them, for
instance a packet that is addressed to an end-point that traverses an
m-box. We call these non-addressed m-boxes. Other times packets are
addressed to the m-box itself, as with a packet being delivered to a
NAT box, or with packets being steered to an m-box. Indeed, a key
feature of NUTSS is that it allows p-boxes to insert addressed
m-boxes into a data path.
Note that we model end-hosts as having an internal p-box and m-box
Francis, et al. Expires October 22, 2007 [Page 4]
Internet-Draft An EME Signaling Protocol Design April 2007
that can initiate and receive signaling messages as well as filter
packets.
Any network (or host) that has policies (i.e. reasons to allow,
disallow, or modify a flow), and that is in the datapath of a flow,
must have one or more p-boxes and one or more m-boxes. Note that
p-box functionality may be deployed in a box that is in the data-
path, and may also be deployed in the end-hosts themselves. These
p-boxes and m-boxes work in concert with each other as follows:
2.2. Name-routing between P-boxes
Any given p-box may have one or more "parent" p-boxes. This would
almost always be the case for the p-box embedded in the end-host.
For non-end-host p-boxes, a typical reason for this would be because
the p-box is behind a firewall controlled by another organization.
When a message is routed from a p-box to one of its parents, we say
the message is being routed "up". Likewise when a message is being
routed from parent to child, it is being routed "down". When a p-box
routes a message to another p-box that is neither its parent or
child, we say it is being routed "across". (Note that when we say
"parent", we mean immediate parent, not an ancestor (parent's parent,
etc.)
A p-box will typically discover its parent(s) through configuration:
DHCP if the p-box is in an end-host, manually otherwise. Auto-
discovery of p-boxes is also possible, as mentioned in Section 2.3.
P-boxes must be able to directly exchange packets with their parent
and children p-boxes, but not with non-parent ancestors or non-child
descendents.
When an end-host registers with its p-box, the registration is passed
up, parent-to-parent, to all ancestor p-boxes. This way, p-boxes
know which child to route messages to. When a p-box has a message to
route, it forwards the message down if it has received a matching
registration for the destination endpoint name (URI) from a child
p-box. Otherwise, if it has one or more parents, it forwards the
message up to one or more of them. Otherwise, if it has no parent,
it does a DNS lookup to learn the IP address of the p-box associated
with the DNS name in the destination URI, and forwards the message
there. (This is obviously very much like how SIP messages are
routed.)
Besides this, p-boxes must know how to route, via zero or more
intermediate p-boxes, to all ancestor p-boxes. This is because
m-boxes can refer endhosts to ancestor p-boxes (Section 2.3). Since
p-boxes (including those in the endhost) may have multiple parents,
they need to know which of multiple parents to use to reach a given
Francis, et al. Expires October 22, 2007 [Page 5]
Internet-Draft An EME Signaling Protocol Design April 2007
ancestor p-box. This can be done by having p-boxes advertise all
known ancestor p-boxes to their children.
From the above description, it should be apparent that a name-routed
message may take multiple up or down hops, but won't take more than
one across hop. While strictly speaking we don't disallow more than
one across hop, neither do we provide a mechanism for letting p-boxes
know how to navigate more than one across hop. Future work, however,
may uncover a reason for doing so.
2.3. Relationship between P-boxes and associated M-boxes
When a p-box approves a flow (perhaps after participating in the
negotiation of flow parameters), it provides security tokens that its
corresponding m-box(es) use to allow the flow in both directions.
The tokens might be cryptographic based on shared information between
p-box and m-box (a self-authorizing token), or contain a simple
directive for the m-box to contact the p-box to approve the flow (a
contact token). The tokens are conveyed by name-routed signaling to
the end-hosts, which then insert them address-routed.
If an m-box receives a packet for an unauthorized flow, it can refer
the end-host to the m-box'es associated p-box, thus allowing the end-
host to obtain a token. It does this by giving both the name and IP
address of the p-box. If the referred p-box is a parent, the end-
host can do name-routed signaling directly with the parent. If the
referred p-box is a non-parent ancestor, then the end-host can
indicate that the signaling message must reach that p-box, and route
the message accordingly.
It is this combination of tokens (in the p-box to m-box direction)
and referrals (in the m-box to p-box direction) that couples the two
signaling paths together. This approach solves many if not all of
the problems that result from the fact that name-routed signaling
cannot always know what the path of a subsequent data flow will be.
For instance, if a p-box PA authorizes a flow through m-box MA, and
the flow actually goes through m-box MB, then MB can refer the end-
host to its associated p-box PB, which can then provide the right
token.
Referrals can also be used for auto-discovery of p-boxes by end-
hosts: the end-host can discover the p-box by trying to transmit a
packet to a global address. The m-box receiving the packet can
reject the flow and refer the end-host to the p-box. Indeed this
same trick can be used to allow a p-box to discover another p-box.
(Note however that more generally a configuration tool like DHCP will
be used to tell end-hosts of their associated p-boxes.)
Francis, et al. Expires October 22, 2007 [Page 6]
Internet-Draft An EME Signaling Protocol Design April 2007
In cases where a p-box and associated m-box are not co-resident in
the same device, the coupling between p-boxes and their associated
m-boxes requires certain configuration at p-boxes and m-boxes, as
follows:
1. The m-box and p-box must almost certainly share cryptographic
keying information. This is needed for instance if self-
authorizing tokens are used, and is desired even if contact
tokens are used.
2. The m-box needs to know the name and IP address of the p-box.
This is in order to be able to refer end-hosts with unauthorized
flows to the appropriate p-box. But it is also needed to prevent
end-hosts from spoofing contact tokens (i.e. inserting a bogus
p-box address in the token).
3. If the p-box is positioned "outside" of the network protected by
the m-box, then the m-box must have firewalls rules that allow
hosts within the network to communicate with the p-box.
4. If the m-box is a NAT box, then the p-box must know the public
address(es) of the NAT box. Even if the m-box is not a NAT, the
p-box may need to know the public-side address of the m-box in
order to steer incoming flows to the m-box.
5. If the p-box wants to steer outgoing flows to a given m-box (or
for that matter any m-box), then the p-box needs to know the IP
address of the appropriate interface (i.e. the private-side
interface if the m-box both private and public interfaces).
2.4. High-level approach to dual signaling
As a general rule, certain information can be established with name-
routed signaling, and certain other information requires address-
routed signaling. Furthermore, in some complex situations, address-
routed and name-routed signaling may have to be interspersed. For
instance, in cases where the name-routed signaling path doesn't match
the address-routed path chosen by routing, additional name-routed
signaling may be required. To the extent possible, signaling
operates such that endpoints can tell what information is still
missing, and so can trigger whatever kind of signaling is needed to
establish that information.
The broad approach to dual signaling is that the endpoints try,
through a series of signaling messages that travel from endpoint to
endpoint via p-boxes or m-boxes, to establish all the information
needed to start the data flow. The same signaling message format is
used for both name-routed and address-routed. The only difference is
Francis, et al. Expires October 22, 2007 [Page 7]
Internet-Draft An EME Signaling Protocol Design April 2007
that name-routed messages are routed by name (of the destination
endpoint), and address-routed messages are routed by IP address (of
the destination endpoint and middleboxes). Typically, signaling will
start name-routed (because the endpoints don't have an IP address to
use), and then simply continue address-routed at the point in time
where name-routed left off. Indeed, where p-boxes and m-boxes are
co-resident, there is no distinction between name-routed and address-
routed.
Broadly speaking, name-routed signaling is required when the end-
points don't have an IP address to address-route signal with.
Address-routed signaling commences when name-routed signaling
provides the IP addresses needed for address-routed signaling, and
indicates that no more information can be obtained through additional
name-routed signaling. Address-routed signaling continues, possibly
through multiple parallel m-boxes, until enough information has been
established (for instance NAT state in m-boxes) to start data flows.
If name-routed signaling provides all the information needed for the
data flow, then address-routed signaling is unnecessary. Information
gathered during signaling is cacheable. As a result, often endpoints
will be able to establish a new flow using only address-routed
signaling, or with no additional signaling at all.
Finally, note that flow authorization using tokens at m-boxes may be
in-band as well as out-of-band.
Francis, et al. Expires October 22, 2007 [Page 8]
Internet-Draft An EME Signaling Protocol Design April 2007
3. Signaling Details
In general, name-routed signaling does the following:
1. Authorizes flows (named endpoints and application).
2. Authenticates endpoints (needed for authorization).
3. Negotiates the protocol stack for the flow.
4. Establishes (some of the) parameters needed for the data flow
(addresses and ports). At a minimum, the addresses needed to
send address-routed signaling messages is required.
5. Conveys tokens needed by m-boxes to authorize the data path.
6. Conveys application data where appropriate.
Address-routed signaling does the following:
1. Presents tokens to m-boxes.
2. Refines the protocol stack negotiations.
3. Establishes any additional parameters needed for the flow.
4. Conveys additional application data where appropriate.
Towards this end, signaling messages (both name- and address-routed)
have two components, a "device", and "data".
A device can represent either an end host or an m-box. Signaling
messages must start with at least two devices, one for each end-host.
Typically a signaling exchange will start with a message that
contains the end-host devices, and additional devices are added by
p-boxes. As the message progresses through p-boxes, additional
devices are added as needed, for instance to represent NAT boxes,
firewalls, or other middleboxes.
As a general rule, information may only be added to a signaling
message as it traverses p-boxes and m-boxes. For instance, an m-box
device with its protocol stack and IP address may initially be
created by a p-box (and signed by that p-box). Later, the m-box
itself may decide to change the IP address and add a port number.
Mechanistically, the additional information would be added in the
form of a new device component, signed by the m-box. Both the old
and new IP addresses would still be there, but it would be understood
that the new IP address over-rides the old one.
Francis, et al. Expires October 22, 2007 [Page 9]
Internet-Draft An EME Signaling Protocol Design April 2007
If it is necessary to literally remove information (not override),
this is done through a "backtrack", whereby the message is reverse
routed to the box that added the offending information, which can
then replace it based on the information passed back to it. For
instance, an endhost p-box may include its IP address in the original
signaling message, but a p-box may later wish not to include it until
the remote end has been authenticated and authorized. The only way
to do that is to backtrack the message to the endhost with an
indication to remove the IP address. (Later, after the flow is
approved, the IP address can be added back in.)
After a signaling message passes once through the complete set of
p-boxes from initiating endpoint to receiving endpoint, there should
be a device component in the message for every m-box that is expected
to be in the data path.
A device component may contain the following information:
1. Names (including endpoint and application)
2. Data Stacks (and associated parameters)
3. Authorizing Tokens (or Token for short)
4. Authenticator (Cert or Challenge/Response)
The Name (a URI) is mandatory for end-host devices, and describes
both the endpoint and the application. The endpoint may be the
machine, a user, a process, and so on. M-box devices may or may not
have endpoint names or application names associated with them, but
typically won't (an IP address will suffice). A name can be
"anonymous".
A Data Stack is literally a list of the stack(s) of protocols that
can run on the device, and parameters associated with each of the
protocols in the stack (i.e. IP address or port). When listed for
an endpoint, it contains the protocols from the lowest network layer
to just below the application. Stating the available stacks allows
for negotiation of protocol, including security protocols, and makes
it easier to introduce new protocols into the Internet. (For
instance, two endpoints can negotiate the use of IPv6 or SCTP as soon
as they, and any m-boxes that care, have it.) The data stack also
serves to supply the protocol parameters needed for a data flow.
A data stack for an m-box specifies what protocols are terminated or
modified at the m-box. For instance, a NAT box might be described as
terminating IP (because it changes the addresses), but only modifying
TCP (because it does not send ACKs). The data stack would also
Francis, et al. Expires October 22, 2007 [Page 10]
Internet-Draft An EME Signaling Protocol Design April 2007
indicate the parameters needed at the NAT box for the flow (i.e. IP
address, TCP port). Note that in this case, it might be a p-box that
supplies the NAT boxes address (during name-routed signaling), but
the m-box itself that later supplies the port (during address-routed
signaling). An HTTP proxy, on the other hand, would be described as
terminating HTTP (and by extension, everything below HTTP). M-box
data stacks, then, serve to inform endpoints as to what is going on
in the network, as well as conveys data parameters needed to traverse
middleboxes.
Tokens carry flow authorizations. When supplied by a p-box, they
indicate that a flow is approved to traverse one or more m-boxes.
When supplied by an m-box, they indicate that the flow is enabled at
the m-box (pending establishment of flow parameters like NAT port
mappings). Note that a device component with only a token (no name
or data stack) suggests that there is an m-box that requires the
token for traversal, but does not modify any data protocols.
An authenticator may contain either a certificate or a challenge/
response. (This is not further discussed.)
Data is information that normally would be carried in the initial
part of the data flow, but is piggybacked onto signaling messages for
better performance. For instance, for HTTP, the initial signaling
message might carry the headers in the TCP SYN and the HTTP GET that
would normally be carried in the first and third packets of the data
flow. The responding signaling message might carry the headers the
the resulting TCP SYN/ACK and the first part of the HTTP reply.
After the first two signaling messages, the now established TCP
connection could simply pick up where it left off. In contrast to
the device components, which are required for NUTSS to work, the data
component is an optimization meant to reduce the number of round
trips needed to establish a flow. We need to carefully consider the
pros and cons of this optimization before deciding whether we want it
or not.
As a signaling message flows through the p-boxes and m-boxes that
process it, each box can do the following:
1. Add a device component.
2. Append an existing device component with additional elements.
3. Negate or over-ride an element from an already existing component
(by adding an element that negates the previous element).
4. Backtrack a message in order to remove an element from an already
existing component.
Francis, et al. Expires October 22, 2007 [Page 11]
Internet-Draft An EME Signaling Protocol Design April 2007
5. Redirect the previous hop in the signaling path to a different
p-box or m-box. In other words, it tells the previous hop to
send the same signaling message to another p-box or m-box.
6. Replicate a message (to explore multiple parallel paths through
the network, as with multi-homed sites). (The issue of whether
to replicate messages to multiple identically named endpoints, as
with SIP forking, needs to be studied.)
7. Explicitly reject a signaling message.
8. Silently drop a signaling message.
In addition to the above, an m-box, upon receiving a disallowed data
flow, can refer the endpoint to a p-box that can authorize (or
reject) the flow.
Francis, et al. Expires October 22, 2007 [Page 12]
Internet-Draft An EME Signaling Protocol Design April 2007
4. Examples
Following are some examples to clarify and flesh out the above
"design". These example focus on illustrating the coupling between
name-routed and address-routed messages. As such, there are many
examples that are, at least for the time being, left out. In
addition, any separate messages resulting from authentication are
also not shown (and the "Authenticator" elements of the device
components are not shown).
Note that we acknowledge that the syntax in these examples (such as
it is) is somewhat high-level. We are trying to strike a balance
between too much detail (which would obscure the operation), and not
enough detail (which would prevent the reader from understanding what
is happening).
4.1. Case A
In this case, there are two single-homed sites, where both ends have
p-box functionality in the (m-box) NAT boxes. This illustrates the
conveyance of NAT mapping information. The topology is as follows,
where H1 and H2 are the endhosts in sites 1 and 2, and M1 and M2 are
the NAT boxes.
+-------+ +-------+ +-------+
| | | | | |
| H1 |--M1--| |--M2--| H2 |
| | | | | |
+-------+ +-------+ +-------+
Site 1 Internet Site 2
A.1 H1->M1 (name routed):
H1-dev[Name(H1name, appName),
Stack(IP-TCP, IPaddr, TCPport)
]
H2-dev[Name(H2name, appName)
]
H1-Data[TCP SYN, App data
]
A.2. M1: DNS lookup on H2name, returns M2 IP address.
A.3. M1->M2 (name routed):
H1-dev[...same as before...] H2-dev[...] H1-Data[...]
M1-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport),
Token("flow enabled at m-box")
]
Francis, et al. Expires October 22, 2007 [Page 13]
Internet-Draft An EME Signaling Protocol Design April 2007
A.4. M2->H2 (name routed):
H1-dev[...] H2-dev[...] H1-Data[...] M1-dev[...]
M2-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport),
Token("flow enabled at m-box")
]
A.5. H2->M2 (reverse routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
H2-dev[Stack(IP-TCP, IPaddr, TCPport)
]
H2-Data[TCP SYN/ACK, App data]
A.6. M2->M1 (reverse routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
H2-dev[...] H2-Data[...]
A.7. M1->H1 (reverse routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
H2-dev[...] H2-Data[...]
A.8 data flow
The total signaling path is:
H1-M1-(DNS)-M2-H2-M2-M1-H1
4.1.1. Comments
Note that there are two H2-dev components. One was put in by H1, and
contains names. The next was put in by H2 (in step A.5), and
contains stack info and data. By doing it this way, it is clear
which system put what into the signaling message. Since H2 didn't
negate anything that H1 put in, we can combine information in the two
components. H2 can sign both H2-dev components. (In subsequent
messages, only a single H2-dev component is shown, to represent the
combination of both components.)
M1 and M2 are able to insert tokens indicating that the data flow is
enabled, since they are both p-box and m-box for the later flow.
Internally, M1 and M2 simply keep track of the NAT mapping state
conveyed in the signaling messages, and use this to later identify
and (weakly) authenticate the flow. Because the tokens have already
authorized the flow, there is no need for subsequent signaling: by
the time each endpoint receives the message, all the information
needed to start the flow exists.
Note that, although M1 enabled the flow in message A.3, it is not yet
able to fill in all of the NAT state, because it does not know what
Francis, et al. Expires October 22, 2007 [Page 14]
Internet-Draft An EME Signaling Protocol Design April 2007
address and port M2 will assign. It learns this when it receives the
message in step A.6. Since messages contain a history of where they
have been, it is possible by observing a message to know if m-boxes
have adequate state (i.e. NAT state) for forwarding packets. Indeed
this is how hosts know to stop sending messages.
The notation "IP-TCP" in the stack of step A.1 is meant to indicate
that host H1 plans to use IP and TCP for this application. The
IPaddr and TCPport refer to these protocols. Though we don't show
it, H1 could have listed several stacks (IP-TCP, IP-IPsec-TCP, IP-
TCP-SSL, etc.) as a way of negotiating protocol, and given the
relevant parameters for each. Subsequent boxes could have pruned the
set, ultimately selecting one stack. The stack "IP-TCP-IP" for the
m-boxes is meant to indicate that IP is terminated on each side of
the m-box, and that TCP is modified but not terminated. Obviously
we'll need a nice notation for this.
When H2 receives the message in step A.4, it sees three devices, M2,
M1, and H1. We are assuming that the message syntax allows H2 to
know that 1) M2 is 'up', M1 is 'across', and H1 is 'down', that 2) H2
is therefore on the private side of M2 and the public side of M1, and
that 3) it should therefore use the public address of M1 as the
destination address of transmitted data packets.
In this example (and subsequent examples), we assume that the boxes
are sufficiently authenticated. Note however that if challenge/
response authentication is being used, then an extra signaling leg is
needed for the responses and associated enabling of the flow.
"Name routed" means that the name is used to route the message. So,
H1->M1 is learned through configuration of H1 (DHCP or dynamic
discovery), M1->M2 learned through DNS, and M2->H2 through a
registration.
"Reverse routed" means that the return message follows the reverse
path of the initial message. Note that, strictly speaking, the
return message could have been "address routed", which means that the
IP address information needed to route a signaling message exists.
But I think the design is cleaner if return messages follow the
reverse path. (Perhaps H2 could have sent an addr-routed message in
parallel.)
We might want one more leg of the signaling message as an
acknowledgement from H1 to H2.
Francis, et al. Expires October 22, 2007 [Page 15]
Internet-Draft An EME Signaling Protocol Design April 2007
4.2. Case B
H1 is behind a single NAT as with example 1, but H2's site is multi-
homed, and H2 is behind two NAT boxes, both of which act as p-box and
m-box.
+-------+ +-------+ +-------+
| | | |-M21--| |
| H1 |--M1--| | | H2 |
| | | |-M22--| |
+-------+ +-------+ +-------+
Site 1 Internet Site 2
The interesting problem here is that the signaling path may involve
one m-box, while the data path uses the other. There are a number of
ways to handle this case (referral, parallel signaling, and m-box
pinning), as follows:
4.2.1. Case B, Version a
This version shows the use of referral.
Assume that steps identical to steps A.1-A.7 occur, but with M21
instead of M2. Also, assume that DNS returned both M21 and M22 at
step A.2, but that M1 only used the address for M21.
Ba.8 Data flow H1-M1-M21-H2 works, but assume that packets from
H2 are routed by IP to M22. This results in a referral message:
M22->H2 (addr-routed):
Referral message: token needed, obtain from p-box M22.
Ba.9. H2->M22 (name-routed):
H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...]
H2-dev[Name(H2name, appName),
Stack(IP-TCP, IPaddr, TCPport)
]
H2-Data[TCP SYN/ACK, App data]
Ba.10. M22->M1 (name-routed):
H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...]
H2-dev[...] H2-Data[...]
M22-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport),
Token("flow enabled at m-box")
]
Francis, et al. Expires October 22, 2007 [Page 16]
Internet-Draft An EME Signaling Protocol Design April 2007
Ba.11. M1->H1 (name-routed):
H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...]
H2-dev[...] H2-Data[...] M22-dev[...]
Ba.12. H1->M1 (reverse-routed):
H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...]
H2-dev[...] H1-Data[...] M22-dev[...]
Ba.13. M1->M22 (reverse-routed):
H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...]
H2-dev[...] H1-Data[...] M22-dev[...]
Ba.14. M22->H2 (reverse-routed):
H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...]
H2-dev[...] H1-Data[...] M22-dev[...]
Ba.15 data flow (H1<->M1<->M22<->H2)
The total signaling path is:
H1 M1 M21 M22 H2
| | | | |
A.1 - A.4 |====>o====>o=====|====>o
| | | | |
A.5 - A.7 o<====o<====o<====|=====|
| | | | |
A.8 data flow |>>>>>o>>>>>o>>>>>|>>>>>o
| | | x<<<<<|
| | | | |
Ba.8 o | | |---->o
| | | | |
Ba.9 - Ba.11 o<====o<====|=====o<====|
| | | | |
Ba.12 - Ba.14 |====>o=====|====>o====>o
| | | | |
data flow |>>>>>o>>>>>|>>>>>o>>>>>o
data flow |<<<<<o<<<<<|<<<<<o<<<<<o
| | | | |
Legend: >>>>>o Data flow, intercepted at "o" mark,
error at "x" mark
====>o Name-routed or reverse-routed message,
handled at ">o" mark
---->o Address-routed message, handled at ">o" mark
Francis, et al. Expires October 22, 2007 [Page 17]
Internet-Draft An EME Signaling Protocol Design April 2007
4.2.1.1. Comments
Had IP routing chosen to send the H2->H1 data flow through M21, then
steps Ba.8 through Ba.14 would have been unnecessary.
At step Ba.11, H1 now has two valid data paths. H1 needs some
guidance on which to use. If the policy at site 2 is that flows must
traverse the m-box in both directions, then M22 could have negated
the M21 information. If on the other hand, asymmetric flows are ok,
the M22 could leave M21 un-negated, and this could inform H1 that it
can use either path. Even in this case, however, H1 should probably
use the last successfully signaled path.
Note, we can't go on adding components to these messages forever (say
if H2 were mobile and kept traversing new middleboxes). One approach
would be to negate defunct m-boxes as they become defunct, and once
negated, leave them out of future signaling message.
Messages Ba.12 - Ba.14 is essentially an ACK going H1->M1->M22->H2.
This ACK is necessary because any given signaling message must make a
final "ACK" trip so that all involved boxes can see that all other
boxes have seen it. (Note that the second leg of the signaling
message, from H2 to H1, served the purpose of the ACK. This is clear
to H1 because no changes were made in the message between H2 and H1.)
4.2.2. Case B, Version b
This case shows a version of the use of m-box pinning.
This version is identical to example 1, but substituting M21 for M1,
and with step four being changed as follows:
Bb.4. M21->H2 (name-routed):
H1-dev[...] H2-dev[...] H1-Data[...] M1-dev[...]
M21-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport, privIPaddr,
privTCPport),
Token("flow enabled at m-box")
]
The total signaling path is:
H1-M1-(DNS)-M21-H2-M21-M1-H1
Francis, et al. Expires October 22, 2007 [Page 18]
Internet-Draft An EME Signaling Protocol Design April 2007
4.2.2.1. Comments
Specifically, m-box M21 has added a private IP address and TCP port
to its stack. From this, H2 can see the path M21->M1->H1 for its
packets. It sees that each has provided an address and port on H2's
"side" of the network (private side for M21, public side for M1).
Since there is no tunneling indicated in the stacks, H2 can deduce
that it needs to address its packets to the private addr and port of
M21, and can assume that M21 will re-address the packets
appropriately. This will cause packets to be routed through M21, and
so we avoid the referral message of step Ba.8 and subsequent re-
signaling.
Note that if both pinned and non-pinned flows were possible, then M21
would have included two stacks, one indicating pinning and the other
indicating no pinning. In general, the intent is that during
signaling, device components contain all possible means of
communications, and endpoints select from whichever will work E2E.
4.2.3. Case B, Version c
This case shows another version of the use of m-box pinning.
This version is identical to case B, version c, but with steps four
and five being changed as follows:
Bc.4. M21->H2 (name-routed):
H1-dev[...] H2-dev[...] H1-Data[...] M1-dev[...]
M21-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport, privIPaddr,
privTCPport),
Stack(IP-TCP-IP-IP, pubIPaddr, pubTCPport, outerIPaddr),
Token("flow enabled at m-box")
]
Bc.5. H2->M21 (reverse-routed):
H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...]
H2-dev[Name(H2name, appName),
Stack(IP-IP-TCP, IPaddr, IPaddr, TCPport)
]
H2-Data[TCP SYN/ACK, App data]
The total signaling path is the same as example Bb:
H1-M1-(DNS)-M21-H2-M21-M1-H1
Francis, et al. Expires October 22, 2007 [Page 19]
Internet-Draft An EME Signaling Protocol Design April 2007
4.2.3.1. Comments
We see in Bc.4 that M21 has added a stack to its device component
(IP-TC-IP-IP). This stack indicates that M21 can terminate an IP-IP
tunnel on the H2-side of the flow. M21 also provides an IP address
associated with the tunnel. (Note that M21 could have provided yet
another tunnel, IP-GRE-IP, in which case it would have also provided
the GRE Key value.) In step Bc.5, H2 has indicated that it will use
the tunneled stack, and provides addresses for both outer and inner
tunnel. Note that the inner tunnel does get translated by the NAT
box M21.
If H2 does not have tunneling capability, then it will respond with
the stack of example 1, thus effectively rejecting M21's offer of
using a tunnel to pin the route.
4.2.4. Case B, Version d
This shows one version of parallel signaling. In this version, the
signaling from H1->M1->M21->H2 take place as with example Ba. After
that, H2, knowing that it has two p-boxes (M21 and M22), replicates
its signaling message as follows:
Francis, et al. Expires October 22, 2007 [Page 20]
Internet-Draft An EME Signaling Protocol Design April 2007
Bd.5. H2->M21 (reverse-routed):
Leg: H2->M21->M1->M1
H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...]
H2-dev[Name(H2name, appName),
Stack(IP-TCP, IPaddr, TCPport)
]
H2-Data[TCP SYN/ACK, App data]
Bd.6. (addr-routed to M1, then to H1)
Leg: H2->M22->M1->H1
Message:
H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...]
H2-dev[Name(H2name, appName),
Stack(IP-TCP, IPaddr, TCPport)
]
H2-Data[TCP SYN/ACK, App data]
M22-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport),
Token("flow enabled at m-box")
]
M1-dev[Stack(IP-TCP-IP, pubIPaddr, pubTCPport)
]
Bd.7. (reverse routed)
Leg: H1->M1->M22->H2
Message:
H1-dev[...] H2-dev[...] M1-dev[...] M21-dev[...]
M22-dev[...]
The total signaling path is:
H1 M1 M21 M22 H2
| | | | |
A.1 - A.4 |====>o====>o=====|====>o
| | | | |
Bd.5 o<====o<====o<====|=====|
Bd.6 o<----o<----|-----o<----|
| | | | |
Bd.7 |====>o=====|====>o====>o
| | | | |
data flow |>>>>>o>>>>>|>>>>>o>>>>>o
data flow |<<<<<o<<<<<|<<<<<o<<<<<o
| | | | |
Francis, et al. Expires October 22, 2007 [Page 21]
Internet-Draft An EME Signaling Protocol Design April 2007
4.2.4.1. Comments
A few notes on syntax. Step Bd.6 shows complete leg of the message
from H2 to H1 (via M22 and M1) as it would have been received at H1
(in other words, after M22 and M1 added their own device components).
Bd.5 shows the complete leg as well.
In this version, H2 knows that it is multi-homed, and so sends an
address-routed message (in addition to the reverse-routed message,
which essentially acts as an ACK here) to "discover" the likely data
path. The address-routed message is initially addressed to M1.
After M1 receives it, it will address the message to H1. Had the
address-routed message gone to M21 instead of M22, then M21 could
have suppressed one of the duplicate messages. (Note that in Bd.7,
H1 responds with a reverse-routed message because it is not multi-
homed, and so knows that the message will take the right route.)
If site 2's policy is that data flows must be symmetric (traverse the
m-box in both directions), then the messages can indicate that H1
should only use the IP address conveyed in the address-routed
message. In any event, if H1 chooses the wrong m-box, the m-box will
know this (because it hasn't seen an address-routed message), and so
can send a referral to H1 (via the reverse signaling path).
One question is, how does H2 know to replicate the message (versus
example 2A, where the message is not replicated)? Possible answers
are:
1. Default behavior is to replicate when there are multiple parent
p-boxes
2. An earlier referral suggested to H2 that it ought to try
replicating in the future
3. Policy configuration at H2 tells it to replicate
4. Policy configuration at M21 and M22 tell them to tell H2 to
replicate in the signaling message. This is preferable to the
previous answer. because the config is limited to P-boxes.
5. End systems learn over time which destinations match up with
which paths, and try to smartly pick the best p-box, falling back
on referrals when their guess is wrong.
Note that the Data component was also replicated by H2. This is ok
as long as H1 can detect that they are replicates and ignore one of
them.
Francis, et al. Expires October 22, 2007 [Page 22]
Internet-Draft An EME Signaling Protocol Design April 2007
4.2.5. Case B, Version e
This is another version of parallel signaling, but not recommended.
In this version, when M1 does its DNS lookup, it learns of both M21
and M22, and itself replicates the query, as the following message
paths show:
H1 M1 M21 M22 H2
| | | | |
|====>o====>o=====|====>o
| o=====|====>o====>o
| | | | |
o<====o<====o<====|=====|
o<----o<----|-----o<----|
o<====o<====|=====o<====|
| | | | |
data flow |>>>>>o>>>>>|>>>>>o>>>>>o
data flow |<<<<<o<<<<<|<<<<<o<<<<<o
| | | | |
H2 will receive two signaling messages, which may be different from
each other (i.e. a different stack). When H2 receives the first of
the messages, it can replicate the message and reply with a reverse-
routed and an address-routed message, as with example 2D above. When
H2 receives the second message, if it is the same as the first (with
the single exception that it is traversed by a different m-box), then
H2 only needs to reply with a single message via the reverse route
(as shown in the flow diagram above). If the second received message
is different, then H2 should replicate this message and send it both
reverse-routed and address-routed. In this case, it is up to H1 to
decide which of the two received address-routed messages to
subsequently use.
This is probably not the way we want to do this. Better to let a
multi-homed site decide for itself whether it wants to replicate
messages or not. Also, it generates more redundant messages. For
now, lets assume that this approach is not used. Besides this,
replicating the signaling message for a site that has multiple
remotely-deployed p-boxes for the sake of reliability or scale, but
never-the-less is single-homed, makes no sense.
Francis, et al. Expires October 22, 2007 [Page 23]
Internet-Draft An EME Signaling Protocol Design April 2007
5. Case C
In this case, both sites are single-homed with NATs, which serve as
m-boxes (M1 and M2, respectively). Both sites use p-boxes that are
deployed separately from the m-boxes (P1 and P2 respectively). Site
1's p-box is behind the NAT. Site 2's p-box is outside the NAT.
Assume that M1 and M2 are configured to pass P1 and P2 traffic
respectively, and that a static NAT mapping exists to allow global
devices to send packets to P1.
+-------+ +-------+ +-------+
| P1 | | P2 | | |
| |--M1--| |--M2--| H2 |
| H1 | | | | |
+-------+ +-------+ +-------+
Site 1 Internet Site 2
H1 initiates the signaling.
C.1. H1->P1 (name routed):
H1-dev[Name(H1name, appName),
Stack(IP-TCP, IPaddr, TCPport)
]
H2-dev[Name(H2name, appName)
]
C.2. P1: DNS lookup on H2name, returns P2 IP address.
C.3. P1->P2 (name routed):
H1-dev[...] H2-dev[...]
M1-dev[Stack(IP-TCP-IP, pubIPaddr>),
Token("flow approved for <H1,H2,app> tuple")
]
C.4. P2->H2 (name routed):
H1-dev[...] H2-dev[...] M1-dev[...]
M2-dev[Stack(IP-TCP-IP, pubIPaddr),
Token("flow approved for <H1,H2,app> tuple")
]
C.5a. H2->P2 (reverse routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
H2-dev[Stack(IP-TCP, IPaddr, TCPport)
]
Francis, et al. Expires October 22, 2007 [Page 24]
Internet-Draft An EME Signaling Protocol Design April 2007
C.5b. H2->M2 (address routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
H2-dev[Stack(IP-TCP, IPaddr, TCPport)
]
C.6a. P2->P1 (reverse routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
C.6b. M2->M1 (address routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
M2-dev[Stack(IP-TCP-IP, pubTCPport),
Token("flow enabled at m-box")
]
C.7a. P1->H1 (reverse routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
C.7b. M1->H1 (address routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
M1-dev[Stack(IP-TCP-IP, pubTCPport),
Token("flow enabled at m-box")
]
C.8. H1->M1 (address routed, in response to either message C.7a or b):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
]
C.9. M1->M2 (address routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
C.10. M2->H2 (address routed):
H1-dev[...] H2-dev[...] M1-dev[...] M2-dev[...]
M2-dev[Token("flow enabled (H1->H2 direction)")]
]
C.11 data flow
The total signaling path is:
H1 P1 M1 P2 M2 H2
| | | | | |
C.1 - C.4 |====>o=====|====>o=====|====>o
| | | | | |
C.5a - C.7a o<====o<====|=====o<====|=====|
| | | | | |
C.5b - C.7b o<----|-----o<----|-----o<----|
| | | | | |
Francis, et al. Expires October 22, 2007 [Page 25]
Internet-Draft An EME Signaling Protocol Design April 2007
C.8 - C.10 |-----|---->o-----|---->o---->o
| | | | | |
data flow |>>>>>|>>>>>o>>>>>|>>>>>o>>>>>o
data flow o<<<<<|<<<<<o<<<<<|<<<<<o<<<<<|
| | | | | |
5.1. Comments
In steps C.3 and C.4 the port number is not given (unlike steps A.3
and A.4 in Case A) because the p-box cannot know what port number the
m-box might assign.
In C.6b, M2 doesn't put the pubIPaddr because it is already included
and isn't going to change. (Same with M1 at C.7b.)
At C.7b, M1 can create the NAT state for H1->H2 packets at this
point, because it knows the IP addr and port H1 is using. It can
also enable the flow, which we show happening. However, data packets
cannot yet flow because M2 doesn't know the public port M1 has
assigned. This doesn't happen until it receives the message from M1
at step C.9.
In C.9 (C.10), M1 (M2) doesn't need to add a Stack, because all of
the parameters have already been assigned in the previous leg and so
are held in the pre-existing M1-dev (M2-dev) component. (Same for H1
on step C.8.)
Note that in this example, address-routed messages flow in both
directions.
There is a kind-of race condition where, for instance, data packets
sent subsequent to the address-routed signaling message may go faster
than the message (cause of processing delays at the message) and
therefore get dropped at m-boxes that have not seen the message. One
way to deal with this is just to accept a few dropped packets (though
when these trigger referral messages, the end-host would have to know
to ignore them). Another way is of course to wait for an ACK of the
address routed message (which we don't show in the example, but which
certainly could exist). Such ACKs could be E2E, thus bypassing
message processing delays.
Strictly speaking, in this case the m-boxes could have eavesdropped
on the original name- and reverse-routed messages, and in so doing
enabling the flow and adding the appropriate parameters. But in the
general case this may not be possible, so we go ahead and replicate
the reply, address-routed.
Francis, et al. Expires October 22, 2007 [Page 26]
Internet-Draft An EME Signaling Protocol Design April 2007
6. Case D
In this case, both sites are multi-homed with NATs to different ISPs
(not shown), which serve as m-boxes. In the case of site 1, P11 is
the p-box associated with M11, and P12 is the p-box associated with
M12. In the case of site 2, P2 is associated with both M21 and M22.
+-------+ +-------+ +-------+
| P11 |-M11--| P2 |-M21--| |
| | | | | H2 |
| H1 |-M12--| P12 |-M22--| |
+-------+ +-------+ +-------+
Site 1 Internet Site 2
H1 initiates the signaling.
Assume, however, that IP routing uses the following paths:
H1->M21 via M11
H1->M22 via M12
H2->M11 via M22
H2->M12 via M21
In other words, there are no symmetric paths. For instance, if
signaling selects M21 as the m-box at site 2, then packets from H1
will traverse M11. If H2 tries to send its packets to M11, however,
its packets will traverse M22. Therefore, there is no way to create
a symmetric path without m-box pinning.
In these examples, we show message "legs" rather than individual
messages.
6.1. Case D, Version a
In this version, there is no replicated parallel signaling messages
anywhere.
Da.1: (name-routed)
Leg: H1-P11-(DNS)-P2-H2
Message:
H1-dev[Name(H1name, appName),
Stack(IP-TCP, IPaddr, TCPport)
]
H2-dev[Name(H2name, appName)
Francis, et al. Expires October 22, 2007 [Page 27]
Internet-Draft An EME Signaling Protocol Design April 2007
]
M11-dev[Stack(IP-TCP-IP, pubIPaddr>),
Token("flow approved for <H1,H2,app> tuple")
]
M21-dev[Stack(IP-TCP-IP, pubIPaddr),
Token("flow approved for <H1,H2,app> tuple")
]
M22-dev[Stack(IP-TCP-IP, pubIPaddr),
Token("flow approved for <H1,H2,app> tuple")
]
Da.2: (addr-routed to M11 pubIPaddr, then to H1 IPaddr)
Leg: H2-M22-M11-H1
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...]
H2-dev[Stack(IP-TCP, IPaddr, TCPport)
]
M22-dev[Stack(IP-TCP-IP, pubTCPport),
Token("H2-M11 flow enabled")
]
M11-dev[Stack(IP-TCP-IP, pubTCPport),
Token("M22-H1 flow enabled"),
]
Da.3: (addr-routed to M22, then to H2)
Leg: H1-M12-(refer H1 to P12)
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...]
Da.4 (name-routed)
Leg: H1-P12-P2-H2
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...]
M12-dev[Stack(IP-TCP-IP, pubIPaddr>),
Token("flow approved for <H1,H2,app> tuple")
]
Da.5 (addr-routed to M12, then to H1)
Leg: H2-M21-M12-H1
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...]
M12-dev[...]
M21-dev[Stack(IP-TCP-IP, pubTCPport),
Token("H2->M12 flow enabled")
]
M12-dev[Stack(IP-TCP-IP, pubTCPport),
Token("H1-M21 flow enabled")
]
Francis, et al. Expires October 22, 2007 [Page 28]
Internet-Draft An EME Signaling Protocol Design April 2007
Da.6 (addr-routed to M21, then to H2)
Leg: H1-M11-M21-H2
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...]
M12-dev[...]
M11-dev[Stack(IP-TCP-IP, pubTCPport),
Token("H1-M21 flow enabled")
]
M21-dev[Stack(IP-TCP-IP, pubTCPport),
Token("M11-H2 flow enabled"),
]
Da.7 (addr-routed to M11, then to H1)
Leg: H2-M22-M11-H1
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M21-dev[....] M22-dev[...]
M12-dev[...]
Da.8 Data Flow (asymmetric)
H1 M11 P11 M12 P12 P2 M21 M22 H2
| | | | | | | | |
Da.1 |=====|====>o=====|=====|====>o=====|=====|====>|
| | | | | | | | |
Da.2 |<----o<----|-----|-----|-----|-----|-----o<----|
| | | | | | | | |
Da.3 |-----|-----|---->o | | | | |
|<----|-----|-----| | | | | |
| | | | | | | | |
Da.4 |=====|=====|=====|====>o====>o=====|=====|====>|
| | | | | | | | |
Da.5 |<----|-----|-----o<----|-----|-----o<----|-----|
| | | | | | | | |
Da.6 |---->o-----|-----|-----|-----|---->o-----|---->|
| | | | | | | | |
Da.7 |<----o<----|-----|-----|-----|-----|-----o<----|
| | | | | | | | |
Data |>>>>>o>>>>>|>>>>>|>>>>>|>>>>>|>>>>>o>>>>>|>>>>>o
Flow o<<<<<o<<<<<|<<<<<|<<<<<|<<<<<|<<<<<|<<<<<o<<<<<|
| | | | | | | | |
In step Da.1, P2 puts both M21 and M22 devices in the message. It is
understood from the syntax that this is means that either one or the
other m-box may be used. In step Da.2, while both M21 and M22
devices remain in the message, since the message is address-routed
Francis, et al. Expires October 22, 2007 [Page 29]
Internet-Draft An EME Signaling Protocol Design April 2007
through M22, M22 ignores the M21 device component.
Looking at the data flow in the diagram above, we see for instance,
that M11 requires NAT state for packets from H1 to M21, and for
packets from M22 to H1. It is straight-forward to see that M11
obtained that state in messages Da.2 and Da.7.
Less obvious is how M22 obtained its NAT state for packets from H2 to
M11, since M22 never directly receives a packet from M11. In message
Da.2, M22 assigned a port number for the H2-M11 flow, and at that
point in time had all the NAT information it needed except the port
number assignment at M11. However, when M11 assigned its port number
for the H1-M22 flow in step Da.2, that information remained in all
subsequent messages. As a result, when M22 received the message from
H2 in step Da.7, it was able to complete its NAT mapping.
Furthermore, upon receiving the message in step Da.7, H1 can tell
that M22 has the complete NAT state for H2-M11 packets. For that
matter, H2 can guess with reasonable certainty that after it sends
the message in Da.7, M22 will have the needed NAT state, and packets
will be able to flow from H2 to H1. This is because H2 can see that
the previous message it address-routed to M11 traversed M22, and so
this one is likely to do so as well. In other words, both H1 and H2
can know that signaling is complete after step Da.7.
If, say, M11 were to fail, then IP routing would start sending
packets from H1 addressed to M21 via M12. M12 enabled this flow in
step Da.5, and so in principle could forward the message on to M21.
Because that was the last message that M12 saw, it cannot necessarily
know that M21 knows the port number that it assigned. In this case,
M21 does know (from step Da.6), and so as long as the NAT state has
not timed out, packets can continue to flow as soon as IP routing in
site 1 converges. If on the other hand M21 did not know the state,
then either an ICMP error message would be received by M12 (and
forwarded on to H1), or H1 would recognize that packets are not
getting through and retry the address-routed signaling message. In
the case of the ICMP error message, H1 would immediately retry the
address-routed message.
Of course, it isn't desirable that every flow start new signaling
messages as soon an m-box crashes. This raises an interesting point,
which is that in principle H1 and H2 can arrange to "prime" the
failover paths in advance. For instance, after the signaling
exchange prior to the failure, H1 knows of both M21 and M22, and
knows how packets are routed to M21 and M22. While H1 can't know
with certainly how packets will be routed after a failure, in this
and most cases, it can make a good guess. Using name-routed
signaling through m-boxes, H1 and H2 would be able to signal failover
paths.
Francis, et al. Expires October 22, 2007 [Page 30]
Internet-Draft An EME Signaling Protocol Design April 2007
6.2. Case D, Version b
In this version, messages are sent in parallel whenever possible.
Db.1: (name-routed)
Leg A: H1-P11-(DNS)-P2-H2
Message:
H1-dev[Name(H1name, appName),
Stack(IP-TCP, IPaddr, TCPport)
]
H2-dev[Name(H2name, appName)
]
M11-dev[Stack(IP-TCP-IP, pubIPaddr>),
Token("flow approved for <H1,H2,app> tuple")
]
M21-dev[Stack(IP-TCP-IP, pubIPaddr),
Token("flow approved for <H1,H2,app> tuple")
]
M22-dev[Stack(IP-TCP-IP, pubIPaddr),
Token("flow approved for <H1,H2,app> tuple")
]
Leg B: H1-P12-(DNS)-P2-H2
Message:
H1-dev[...] H2-dev[...] (same as leg A)
M12-dev[Stack(IP-TCP-IP, pubIPaddr>),
Token("flow approved for <H1,H2,app> tuple")
]
M21-dev[...] M22-dev[...] (same as leg A)
Db.2: (addr-routed)
Leg A: H2-M22-M11-H1
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...]
M21-dev[....] M22-dev[...]
H2-dev[Stack(IP-TCP, IPaddr, TCPport)
]
M22-dev[Stack(IP-TCP-IP, pubTCPport),
Token("H2-M11 flow enabled")
]
M11-dev[Stack(IP-TCP-IP, pubTCPport),
Token("M22-H1 flow enabled"),
]
Leg B: H2-M21-M12-H1
Message:
Francis, et al. Expires October 22, 2007 [Page 31]
Internet-Draft An EME Signaling Protocol Design April 2007
H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...]
M21-dev[....] M22-dev[...]
H2-dev[Stack(IP-TCP, IPaddr, TCPport)
]
M21-dev[Stack(IP-TCP-IP, pubTCPport),
Token("H2-M12 flow enabled")
]
M12-dev[Stack(IP-TCP-IP, pubTCPport),
Token("M21-H1 flow enabled"),
]
Db.3: (addr-routed)
Leg A: H1-M12-M22-H2
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...]
M21-dev[....] M22-dev[...]
M12-dev[Stack(IP-TCP-IP, pubTCPport),
Token("H1-M22 flow enabled")
]
M22-dev[Stack(IP-TCP-IP, pubTCPport),
Token("M12-H2 flow enabled"),
]
Leg B: H1-M11-M21-H2
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...]
M21-dev[....] M22-dev[...]
M11-dev[Stack(IP-TCP-IP, pubTCPport),
Token("H1-M21 flow enabled")
]
M21-dev[Stack(IP-TCP-IP, pubTCPport),
Token("M11-H2 flow enabled"),
]
Db.4 (addr-routed)
Leg A: H2-M22-M11-H1
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...]
M21-dev[....] M22-dev[...]
Leg B: H2-M21-M12-H1
Message:
H1-dev[...] H2-dev[...] M11-dev[...] M12-dev[...]
M21-dev[....] M22-dev[...]
Db.5 Data Flow (asymmetric):
Francis, et al. Expires October 22, 2007 [Page 32]
Internet-Draft An EME Signaling Protocol Design April 2007
H1 M11 P11 M12 P12 P2 M21 M22 H2
| | | | | | | | |
Db.1 |=====|====>o=====|=====|====>o=====|=====|====>|
|=====|=====|=====|====>o====>o=====|=====|====>|
| | | | | | | | |
Db.2 |<----o<----|-----|-----|-----|-----|-----o<----|
|<----|-----|-----o<----|-----|-----o<----|-----|
| | | | | | | | |
Db.3 |-----|-----|---->o-----|-----|-----|---->o---->|
|---->o-----|-----|-----|-----|---->o-----|---->|
| | | | | | | | |
Db.4 |<----o<----|-----|-----|-----|-----|-----o<----|
|<----|-----|-----o<----|-----|-----o<----|-----|
| | | | | | | | |
Data |>>>>>o>>>>>|>>>>>|>>>>>|>>>>>|>>>>>o>>>>>|>>>>>o
Flow o<<<<<o<<<<<|<<<<<|<<<<<|<<<<<|<<<<<|<<<<<o<<<<<|
| | | | | | | | |
If we assume that the two messages sent in Db.1 indicate that two
messages are being sent, then H2 can wait to receive both messages
before sending its two messages. In this case, both messages can
contain the approvals for both M12-dev[] and M11-dev[]. Effectively
what is happening is that H2 is waiting to receive all approvals
before continuing. As a result, no subsequent signaling message will
be rejected. This is shown in step Db.2.
If on the other hand H2 doesn't wait for both messages, then the
first message it sends would contain an approval for M12-dev[] or
M11-dev[], but not both. As a result, the first address-routed
message sent by H1 would not have the right approval, and would be
rejected. Since H1 would already have sent all of the name-routed
messages it can send, it merely needs to wait for the appropriate
approval to show up (i.e. the second address-routed message from H2),
and try again.
With this parallel signaling, all four possible bi-directional flows
are enabled (even though only half of them can actually be used,
unless there is a failure).
Francis, et al. Expires October 22, 2007 [Page 33]
Internet-Draft An EME Signaling Protocol Design April 2007
7. Security Considerations
There are certainly many. TBD.
Francis, et al. Expires October 22, 2007 [Page 34]
Internet-Draft An EME Signaling Protocol Design April 2007
8. Normative References
[I-D.guha-emerg-requirements]
Guha, S. and P. Francis, "Requirements for the End-Middle-
End Research Group", draft-guha-emerg-requirements-00
(work in progress), February 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Francis, et al. Expires October 22, 2007 [Page 35]
Internet-Draft An EME Signaling Protocol Design April 2007
Authors' Addresses
Paul Francis
Cornell University
4108 Upson Hall
Ithaca, NY 14853
US
Phone: +1 607 255 9223
Email: francis@cs.cornell.edu
Saikat Guha
Cornell University
331 Upson Hall
Ithaca, NY 14853
US
Phone: +1 607 255 1008
Email: saikat@cs.cornell.edu
Scott Brim
Cisco Systems
146 Honness Lane
Ithaca, NY 14850
US
Email: sbrim@cisco.com
Melinda Shore
Cisco Systems
809 Hayts Road
Ithaca, NY 14850
US
Email: mshore@cisco.com
Francis, et al. Expires October 22, 2007 [Page 36]
Internet-Draft An EME Signaling Protocol Design April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Francis, et al. Expires October 22, 2007 [Page 37]
