Re: Upper Layer Protocol ID Proposal

D_P_Sanford <@mwmgate1.mitre.org:D_P_Sanford@caasd1> Mon, 16 May 1994 20:43 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa13968; 16 May 94 16:43 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa13964; 16 May 94 16:43 EDT
Received: from sun2.nsfnet-relay.ac.uk by CNRI.Reston.VA.US id aa18648; 16 May 94 16:43 EDT
Via: uk.ac.ulcc.vmsfe; Mon, 16 May 1994 21:15:15 +0100
Via: UK.AC.NSFNET-RELAY; Mon, 16 May 94 21:09 GMT
Received: from mwunix.mitre.org by sun3.nsfnet-relay.ac.uk with Internet SMTP id <sg.05311-0@sun3.nsfnet-relay.ac.uk>; Mon, 16 May 1994 21:08:53 +0100
Return-Path: D_P_Sanford%CAASD1@MWMGATE1.mitre.org
Received: from mwmgate2.mitre.org (mwmgate2.mitre.org [128.29.155.13]) by mwunix.mitre.org (8.6.4/8.6.4) with SMTP id QAA03185 for <@mwunix.mitre.org:THINOSI@ULCC.AC.UK>; Mon, 16 May 1994 16:08:06 -0400
Message-Id: <199405162008.QAA03185@mwunix.mitre.org>
Date: Mon, 16 May 1994 16:08:17 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: D_P_Sanford <D_P_Sanford@caasd1>
To: THINOSI@ulcc.ac.uk, tulip@fluky.mitre.org, Steve Van Trees <vantrees@fuji.sed.stel.com>
Subject: Re: Upper Layer Protocol ID Proposal
X-Orig-Sender: THINOSI-request@ulcc.ac.uk
X-ULCC-Sequence: 178
X-ULCC-Recipient: ietf-archive%us.va.reston.cnri@uk.ac.nsfnet-relay

Below the value for connectionless session protocol is intended to be the first 
octet of the connectionless session PDU.  I found this value in pre-DIS spec to 
be the value 64, presumeably binary or H '40'.  You show the value to be H '20',
is this correct?

Dave

P.S. Are there some kind of procedural constraints required (like one upper 
layer protocol set per address tuple) on the use of the ULPI, so that for 
example I will never misinterpret a data PDU sent on a connection set up by the 
AARQ for a connectionless session PDU sent to the same address?


Upper Layer Protocol Identifier Proposal
     
1. Background
     
Various industries have expressed immediate needs for 
communications that  require minimum overhead in the upper layer 
standards.  Coordinated work is  ongoing in ITU-T, ISO/IEC JTC 1/SC 
21, OSE Implementors Workshop (OIW), and ANSI to address these 
needs.  In particular, the contents of document TD - 5161 and  TD -
 5183, generated at the ITU-T SG7 meeting 7-18th February, 1994,
should be  referenced.  The approach proposed below combines 
various efforts going on in  ISO, ANSI and ITU-T.  This combines 
Fast Byte proposals in ITU-T with ongoing work for the use of 
A2CSE.
     
2. Technical Approach
     
This paper proposes an expansion of the initial ITU-T concepts on 
fast byte to  allow a single byte to act as an Upper Layer Protocol 
Identifier (ULPI).  The  general fast byte approach is described in 
Appendix K of the ITU-T report, but  some details are not fully 
worked out.  In the context of this paper, the fast  byte would 
identify current standard OSI implementations using the first octet 
of the session connection establishment PDU (Session PDU Identifier 
= H '0D').   As discussed in ITU-T this allows the possibility of 
using a Fast Byte value  (e.g. H '0F'), to indicate a specific 
alternate stack option.
     
Looked at in the wider context, the Fast Byte should be expanded to 
recognize  this value as a one octet flat address space indicating 
various stack options.   Taking an architectural approach modeled 
after the ISO 9577 (Network Layer  Protocol Identifier) standard, 
the Fast Byte octet then identifies multiple  stack options above 
transport, and acts as default header for layers as needed.
     
ACSE is being modified to support the eXtended Application Layer 
Structure  (XALS).  This work is being progressed both in ANSI and 
ISO.  The modification  is in the form of an added functional unit 
to ACSE to allow the ability to  support Application Service 
Objects (ASOs), recursive use of software, and other benefits of 
the XALS structure.  ACSE with extensions is referred to as ASO 
Association Control Service Element (A2CSE).  At various recent 
meetings of ANSI and OIW the majority wish was to define a 
mechanism allowing minimal to no  Session and Presentation PCI 
overhead in an A2CSE stack option.
     
The immediate need within the aeronautical environment is a method 
to support  A2CSE encoded using the unaligned variant of Packed 
Encoding Rule (PER),  immediately following the "fast byte" value 
indicating this option.  While the  idea of having that value 
corresponding to the first octet of the association  establishment, 
was explored, for still greater efficiency, this does not appear
to be possible, because A2CSE encoding options could conflict with 
the H'0D'  value for session.
     
3. Proposal
     
This paper recommends the creation of a Fast-Byte standards 
document and corresponding registration authority.  It recommends 
that ANSI reserve the  initial values of:
     
               > one-bit session   /\   one-bit session
                        0         /  \        1
                                 /    \
                                /      \
                  byte-aligned /\ bit  /\
                      0       /  \1  0/  \ 1
                             /    \  /    \
                            /              \
     
          00'D'  8326 + 8822                00  Transparent 
          10'0'  connectionless session     01  BER
          00'1'  Fast Byte                  10  bit-aligned PER
                                            11  byte-aligned PER
     
'01'   Fast Byte for Session;
     
'0D'   Fast Byte which indicates and is the first octet of 
traditional Session, Presentation, and ACSE;
     
'20'   Fast Byte which indicates and is the first octet of 
connectionless Session, Presentation, and ACSE;
     
'8' for Fast Byte value which implies byte-aligned transparent data 
above the Fast Byte value.
     
'9'    Fast Byte acting as both byte-aligned Session and 
Presentation header, and as the first octet of ACSE encoded using 
BER.
     
'A'    Fast Byte acting as byte-aligned Session and Presentation 
header followed by ACSE encoded using the PER unaligned variant;
     
'B'    Fast Byte acting as both byte-aligned Session and 
Presentation header, followed by ACSE encoded the PER octet-aligned 
variant;
     
'C' for Fast Byte value which implies bit-aligned transparent data 
above the Fast Byte value.
     
'D'    Fast Byte acting as both bit-aligned Session and 
Presentation header, and as the  first octet of ACSE encoded using 
BER.
     
'E'    Fast Byte acting as bit-aligned Session and Presentation 
header followed by ACSE encoded using the PER unaligned variant;
     
'F'    Fast Byte acting as both bit-aligned Session and 
Presentation header, followed by ACSE encoded the PER octet-aligned 
variant;