Subject: [SPIRITS] Some Thoughts On Protocol Requirements

From: Bruce Chapman <[email-masked]>
Date: Mon, 26 Mar 2001 12:19:13 +1200 (NZST)

Hello all,

Sorry this is running quite late, but this has been my 
first opportunity get down some thoughts on 
draft-ietf-spirits-reqs-00.txt

They are thoughts as opposed to opinions, and are personal 
and may not reflect the official views of my employer.

B Interface Requirements
------------------------

Also there seem to be some unusual characteristics of the B ( Server - Gateway) interface, which I think should be considered.

Specifically, there are 'sessions' on B that may be real or virtual. 
These sessions need to have the characteristic that the Gateway can 
determine if the session is still active. 
The unusual charateristics 
are those related to traffic profiles. These sessions will (in the 
case of ICW service at least), last for several minutes, and in some 
cases several hours. However transactions will be at a very low rate 
in the order of 1 transaction per several minutes. There are lots 
(in the order of ten thousand plus) of these sessions in place at any 
one time, possibly more than can be supported by transport protocols with 
'real' sessions due to the 64K limit on TCP sessions per host.

There may be desired latency requirements which affect the transport 
protocol choice, because the transactions are signalling the presence 
of real-time events at the Service Switching Function. 

There is also a requirement that this interface B is/may be secure, since 
it is carried over the internet, and there is an opportunity for fraud if 
it is not. 

These requirements should be discussed.

Thoughts on the requirements Document & Requirements
----------------------------------------------------

Did I miss something?

Where was the discussion that resulted in SIP being chosen as the
transport protocol for spirits?

We have but one sentence in section 4 attempting to justify the choice
of SIP.

The background work in the draft is good but I cannot find any analysis
of the options for the transport protocol.

from my limited experience I think there are at least 3 addtional factors to
consider in choosing the protocol.

1. What are the protocols used at the boundary of the architecture?

2. Do we have a preference for a binary or text based protocol?

3. Do we have a preference for a legacy protocol or not?

Here is my 2 cents worth of analysis:

1. What are the protocols used at the boundary of the architecture?

The draft provides a good analysis of PSTN and Mobile considerations
here, which is the only communication channel crossing the boundary into
or out of the architecture. These protocols are binary and described
with  ASN.1

2. Do we have preference for a binary or text based protocol?

The draft makes fleeting mention of this ( 5.4)

"Neither the use
   of the ASN.1, nor the requirement for binary encoding are the typical
   requirements for the IETF application protocols"   

(eds please note, there is a missing period prior to this sentence !!)

However the draft does not analyse whether this normal lack of
requirement is applicable in this case (as it was for SNMP!)

Personally, I don't see binary encoding as a requirement, but that does
not necessarily mean it is not an option, just as text encoding is not a
requirement but is an option.

Given the use of ASN.1 and binary encoding in the only boundary
protocols, I don't think this option should be dismissed so lightly.

We are probably all familiar with the pros and cons of binary versus
text encoding, but how do those apply to our architecture?
Which of the two has more relevant benefits, and less relevant
negatives?

3. Do we have a preference for a legacy protocol or not?

Do we want something old, with all its embodied wisdom, and warts, or do
we want to start afresh?

If we want a legacy protocol, we could choose an ITU protocol if we also
want binary encoding. 

If we want a text based encoding in a legacy protocol, we can choose
SIP. (this would give us at least 4 preceding generations - SIP
(RFC-2543) son-of  HTTP (RFC-2068 ) son of  MIME (RFC -2045). son-of 
email RFC-822, which says
"This standard specifies a syntax for text messages that  are
     sent  among  computer  users",   

thats quite a lot of accumulated wisdom and warts. 

One of the legacies is that SIP still has the attribute of a compromise
between machine readability / and human readability. Perhaps we could
sacrifice the human readability a little to gain a more easily
implemented protocol which better maps to the requirement that the
protocol can support the type of structured information found in INAP
(and other) messages. (I assume this is an implied requirement from the
draft)

If we want a roll-our-own protocol (non legacy), then we can choose
binary or text. 

If we choose to roll our own binary (but I think not)
we could use ASN.1 to define it. 

If we choose to use a non-legacy text protocol maybe XML is a good
option. (although it could be argued even XML is legacy) 

My conclusions
--------------

XML may well be the best way to encode the structured data in the INAP
messages at the boundary of the architecture into a text based protocol
for use within the architecture. 

Given that there are standard, machine readable definition 'languages'
DTD for XML and ASN.1 for INAP et al, then automatic code generation of
the translator would offer many benefits.

There has been some work looking at encoding various ITU/T protocols
into SIP, but these merely put the ITU/T message into the body as a new
MIME type. This approach means that each element in the architecture
needs to support SIP as a transport protocol, then be able to decode the
embedded INAP message. If as builders of SPIRITS applications we have to
do that, would it not be easier to drop SIP and just decode the binary
ASN.1 encoded data? 

There are some unusual requirements and characteristics on the B interface 
which may make most commonly used tranport protocols unacceptable.

regards

Bruce

-------------------------------------------------------
Bruce Chapman, Software Systems Architect,
NEC New Zealand
LEVEL 6
CORNER TARANAKI AND MANNERS STREETS
WELLINGTON
PHONE: 64  4  381-6279
FAX:   64  4  381-1110
EMAIL: [email-masked]
--------------------------------------------------------

_______________________________________________
SPIRITS mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/spirits

---

From: Bruce Chapman <[email-masked]>
Date: Thu, 29 Mar 2001 17:47:13 +1200 (NZST)

Alec summarized ...

> 2. SIP seems to be a "natural" transport vehicle for SPIRITS
> parameters ("We based PINT on SIP - it works for
> us, so you may need to give some details on why it doesn't work for
> SPIRITS. . . we didn't have to re-invent a
> worldwide infrastructure" - LC).
> 

As pointed out in my earlier emails, the B interface has some unusual characteristics. 

I dont think we can just assume therefore that because SIP worked for PINT, it will work for SPIRITS where (for ICW service at least) the thousands of SERVERs are vagrants. (my term, it has no fixed abode, it may be old fashioned, it is possibly antisocial, it is certainly unmanaged, it probably won't have trusted relationship with anything (crytographically speaking) (unless we build one), its platforms may have worn thin, you don't know its whereabouts, and it may just disappear without warning)

This doesn't mean that SIP wont work, it just means that we need to explore all the implications of having many vagrant SERVERs, and factor this into our choice of transport protocol.

Someone convince me please.

regards

Bruce