[Nsis-imp] The MRI format
"Hancock, Robert" <robert.hancock@roke.co.uk> Thu, 12 May 2005 12:37 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1DWCwK-0004cq-8q; Thu, 12 May 2005 08:37:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1DWCwJ-0004cl-7l
for nsis-imp@megatron.ietf.org; Thu, 12 May 2005 08:37:19 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1])
by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19932
for <nsis-imp@ietf.org>; Thu, 12 May 2005 08:37:17 -0400 (EDT)
Received: from rsys001x.roke.co.uk ([193.118.201.108])
by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWDC2-0000Mk-0q
for nsis-imp@ietf.org; Thu, 12 May 2005 08:53:34 -0400
Received: from rsys002a.roke.co.uk (rsys002a.roke.co.uk [193.118.192.251])
by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id j4CCavqP012963
for <nsis-imp@ietf.org>; Thu, 12 May 2005 13:36:57 +0100
Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2657.72)
id <JF3JXG31>; Thu, 12 May 2005 13:37:53 +0100
Message-ID: <3F2E01E1D7B04F4EBEC92D3FA324D8807DD327@rsys004a>
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: nsis-imp@ietf.org
Date: Thu, 12 May 2005 13:35:02 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
X-MailScanner-rsys001x: Found to be clean
X-MailScanner-From: robert.hancock@roke.co.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc:
Subject: [Nsis-imp] The MRI format
X-BeenThere: nsis-imp@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: List for implementation questions for NSIS protocols
<nsis-imp.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis-imp>,
<mailto:nsis-imp-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/nsis-imp>
List-Post: <mailto:nsis-imp@lists.ietf.org>
List-Help: <mailto:nsis-imp-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis-imp>,
<mailto:nsis-imp-request@lists.ietf.org?subject=subscribe>
Sender: nsis-imp-bounces@lists.ietf.org
Errors-To: nsis-imp-bounces@lists.ietf.org
Hi all,
when we did our unofficial testing in Minneapolis, we found a number of issues with the MRI format (the flow-id), and some have subsequently been raised on this list.
I'm updating the text for the -06 version, and a copy of the latest version is included below. People might like to comment on its comprehensibility.
There is a specific issue about the syntax: should we try to pin down precisely the meaningful combinations of flag values, protocol values, and all the interrelationships between them (which could get very complex and not particularly interesting), or should we rely on common sense and the ability to send meaningful error messages?
It might be that a minimal set of capabilities needs to be identified (e.g. MUST understand the port fields if the protocol field is UDP/TCP) without saying that other combinations are explicitly prohibited. Or should we be more prescriptive?
cheers,
robert h.
text follows:
=============================================================================
C.4.1 Message-Routing-Information
Type: Message-Routing-Information
Length: Variable (depends on message routing method)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message-Routing-Method | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
// Method-specific addressing information (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C.4.1.1 Path-Coupled MRM
In the case of basic path-coupled routing, the addressing information
takes the following format:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IP-Ver |P|T|F|S|A|B|D|Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Source Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Destination Address //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Prefix | Dest Prefix | Protocol | Traffic Class |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Reserved | Flow Label :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: SPI :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Source Port : Destination Port :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The flags are:
P - IP Protocol
T - Traffic Class
F - Flow Label
S - SPI
A - Source Port
B - Destination Port
D - Direction of message relative to MRI
The contents of the Protocol field is only interpreted if P is set.
The contents of the Traffic Class field is only interpreted if T is
set. The S/A/B flags can only be set if P is set.
F may only be set if IP-Ver is 6. If F is not set, the entire 32 bit
word for the FLow Label is absent.
If either of A, B is set, the word containing the port numbers is
included in the object. However, the contents of each field is only
significant if the corresponding flag is set; otherwise, the contents
of the field is regarded as padding, and the MRI refers to all ports
(i.e. acts as a wildcard). If the flag is set and Port=0x0000, the
MRI will apply to a specific port, whose value is not yet known. If
neither of A or B is set, the word is absent.
Likewise, the SPI field is only present if the S flag is set.
The Direction flag has the following meaning: the value 0 means 'in
the same direction as the flow' (or "downstream"), and the value 1
means 'in the opposite direction to the flow' (or "upstream").
===========================================================================
_______________________________________________
NSIS-imp mailing list
NSIS-imp@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/nsis-imp
- [Nsis-imp] The MRI format Hancock, Robert