RE: [EME] finally!: draft-irtf-eme-francis-nutss-design-00.txt

"Paul Francis" <francis@cs.cornell.edu> Tue, 08 May 2007 18:05 UTC

Return-path: <eme-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlU3j-0008Bj-TD; Tue, 08 May 2007 14:05:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlU3i-0008BZ-L3 for eme@irtf.org; Tue, 08 May 2007 14:05:10 -0400
Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlU3i-0002s6-Ag for eme@irtf.org; Tue, 08 May 2007 14:05:10 -0400
Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 14:05:09 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [EME] finally!: draft-irtf-eme-francis-nutss-design-00.txt
Date: Tue, 8 May 2007 14:05:06 -0400
Message-ID: <E6F7A586E0A3F94D921755964F6BE006BADAA6@EXCHANGE2.cs.cornell.edu>
In-Reply-To: <183BD76A-A994-4E22-B20E-82319811AD07@iki.fi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [EME] finally!: draft-irtf-eme-francis-nutss-design-00.txt
Thread-Index: AceRMr+9Py65BshiTe+rsn8ki8Gj4QAZl9zA
From: "Paul Francis" <francis@cs.cornell.edu>
To: "Teemu Koponen" <tkoponen@iki.fi>
X-OriginalArrivalTime: 08 May 2007 18:05:09.0332 (UTC) FILETIME=[6A55E140:01C7919B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: eme <eme@irtf.org>
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Errors-To: eme-bounces@irtf.org

 
Sure.  I know my notation is a bit incomplete here...I was trying to find a
balance between readability and specificity.  In general, I was hoping that
the comments following each message exchange would clarify the notation.

By way of explanation, here's a snippet from the draft:

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")
   ]

H1->M1 means that it is going from H1 to M1 (most of the examples have a flow
diagram at the end that summarizes the flow)

(name routed) means that it was routed using the name

H1-dev means that this component of the message is a device describing host
H1.  (Recall that there are two types of message components, "device" and
"data", see section 3)

within the H1-dev component, there is a name and a stack.  

The name contains the name of H1 ("H1name") and the name of the app
("appName")

The stack contains the protocols used ("IP-TCP"), the address of the IP
protocol for H1 ("IPaddr") and the TCP port ("TCPport").  e.g. 20.1.2.3 and
45221.

The data component H1-Data says that the data normally in a TCP SYN packet
and the first application packet are included.

In the message labeled A.3., a component such as H2-dev[...] means that the
component already given in an earlier message is simply repeated (carried
along).  In general, components are not deleted as the message makes it way
back and forth, they are only added.

In the token component, "flow enabled at m-box" means that the m-box has
approved the flow, and will allow packets to pass once all the needed
parameter information is conveyed (i.e. the address on the remote end).
Normally, when a p-box approves a flow, we'll write "approved" instead of
"enabled" (as in "flow approved for <H1,H2,app> tuple").

Let me know if you have more questions.

PF



> -----Original Message-----
> From: Teemu Koponen [mailto:tkoponen@iki.fi] 
> Sent: Tuesday, May 08, 2007 1:35 AM
> To: Paul Francis
> Cc: eme
> Subject: Re: [EME] finally!: 
> draft-irtf-eme-francis-nutss-design-00.txt
> 
> On Apr 24, 2007, at 11:10, Paul Francis wrote:
> 
> Paul,
> 
> > After weeks of quiet, we have finally generated a draft design/ 
> > architecture (called NUTSS) for the EME research group.  Its posted 
> > at:
> >
> >
http://www.ietf.org/internet-drafts/draft-irtf-eme-francis-nutss-design-00.tx
t
> 
> Could someone of the authors give hints how to decipher the 
> notation used in the examples?
> 
> TIA,
> Teemu
> 
> --
> 
> 

_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme