Subject: [NSIS] RE: Operational QoS signaling protocol requirements

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 2 May 2002 13:03:50 +0200

Marcus

> Actually, I am not that sure about the extensibility req. I 
> got the feeling that too much extensibility is too complex
> and finding the right degree is very difficult, therefore
> I would not pose extensibility as a major req (a MAY)

If there's a basic protocoll and a service specific one, then the service specific one is a major extension. If NSIS is going to build this, then the service specific protocol would have to be extensible. The basic protocol must be stable. The basic protocol is just ruling some generic and always recurring dialogue types. If that is the direction NSIS is taking now, I agree - extensibility must be built into the service specific part of the protocol, not into the basic protocol.
 
> If I understood "5.12.6 Reliable Communication" right you do not mean 
> reliable transport of signaling message or?

I also mean reliable transport of the signalling message. They must arrive at their destination as they were sent. I don't look at real-time transmission beeing a critical requirement for signaling message transfer. I'd prefer to waste some milliseconds if that ensures error- and loss free transmission of signaling information.

Regards, Rüdiger

> --On Thursday, May 02, 2002 11:56 AM +0200 "Geib, Ruediger" 
> <[email-masked]> wrote:
> 
> > Dear Markus,
> >
> > By and large operational NSIS protocol requirements miss in the
> > requirements draft. I'd suggest to add:
> >
> > 5.12 Operational Stability
> > The design of an NSIS protocol must provide a maximum of operational
> > stability. The state of a unit involved into NSIS signalling must be
> > stable no matter what the surronding conditions are. This 
> leads to the
> > following requirements:
> >
> > 5.12.1 Backwards compatibility
> > A later version of an NSIS protocol must be backwards 
> compatible with
> > earlier versions of an NSIS protocol.
> >
> > 5.12.2 Unexpected situations and error restistance
> > An NSIS protocol must define behaviour of NSIS signaling 
> units during
> > unexpected situations. Unexpected situtions are unknown messages,
> > parameters and parameter settings as well as receiption of 
> unexpected
> > messages (e.g. a "Reservation Confirmation" without prior 
> "Reservation
> > Request").
> >
> > 5.12.3 Default behaviour
> > An NSIS protocol must define default behaviours and 
> parameter settings
> > wherever applicable.
> >
> > 5.12.4 Extendability
> > An NSIS protocol must provide means to enhance a protocol 
> with future
> > procedures, messages, parameters and parameter settings.
> >
> > 5.12.5 Preventation of stale state
> > An NSIS signalling protocol must provide means for an NSIS 
> signaling unit
> > to discover and remove local stale state. This may for 
> example be done by
> > means like soft state and periodic flooding or by a polling 
> mechanism and
> > hard state signaling.
> >
> > 5.12.6 Reliable Communication
> > NSIS signaling procedures, connectivity between units 
> involved in NSIS
> > signaling as well as the basic transport protocol used by NSIS must
> > provide a maximum of communication reliability. Procedures 
> must define
> > how an NSIS signaling systems behaves if some kind of 
> request it sent
> > stays without answer (this could require e.g. be timers, number of
> > message retransmits and release messages).  An NSIS 
> signaling unit must
> > be able to check its connectivity to an adjacent NSIS 
> signaling unit at
> > any time (this requirement must however not result in a DoS 
> attack tool -
> > the frequency of these checks must be limited, and flow 
> control may be
> > useful).  The basic transport protocol to be used between 
> adjacent NSIS
> > units must ensure message integrity and reliable transport.
> >
> > 5.12.7 Smooth breakdown
> > A unit participating in NSIS signaling must no cause 
> further damage to
> > other systems involved in NSIS signaling when it has to go 
> out of service.
> >
> > Regards, Rüdiger
> >
> >
> > Rüdiger Geib
> > Senior Expert
> > T-Systems Nova GmbH
> > Technologiezentrum
> > Am Kavalleriesand 3, 64295 Darmstadt
> > Germany
> > Fon: +49 6151 832138
> > Fax: +49 6151 838103
> > mailto:[email-masked]
> > http://www.t-nova.de
> >
> 
> 
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
> 
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 2 May 2002 15:10:13 +0200

Thanks Marcus, you made the point.

> >>> signaling unit to discover and remove local stale state.
> >>> This may for example be done by means like soft state
> >>> and periodic flooding or by a polling mechanism and hard state
> >>> signaling.

> > Georgios:
> > I do not understand this requirement!
> > maybe we could just add a sentence in Section 5.3.1 about 
> > the soft state release  of resources!
> > I thought we had specified that somewhere!

> Marcus said: 
> I think we are not requiring soft state, but soft state is a 
> solution to that requirement I think.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 2 May 2002 15:59:57 +0200

Georgios,

my comments in line.

G> I think that Operational stability is closer to the 
G> implementation process!!

In my view designing protocols which may operate 
stable is an activity starting with protocol design.  
 
R> 5.12.2 Unexpected situations and error restistance
R> An NSIS protocol must define behaviour of NSIS signaling units 
R> during unexpected situations. Unexpected situtions are 
R> unknown messages, parameters and parameter settings as
R> well as receiption of unexpected messages (e.g. a 
R> "Reservation Confirmation" without prior "Reservation Request").
 
G> This requirement is somehow similar to Open issues (53)
G> and requirement 5.3.4. Moreover this requirement is
G> emphasizing to many details that might not be necessary!

5.3.4 refers to behaviour in the case of problems in the data
plane. My suggestion here is about unexpected events/errors
in the control plane. If you think that this point carries
to many details, let's split it up in several individual
requirements.
 
R> 5.12.3 Default behaviour
R> An NSIS protocol must define default behaviours and parameter 
R> settings wherever applicable. 
G> What do you mean wherever applicable? Is this service specific?

Reworded 5.12.3 Default behaviour
An NSIS protocol must define default behaviours and parameter 
settings wherever NSIS allows for a set of options.

This is a basic state of the art signaling design paradigm. 
It is not service specific. 
 
R> 5.12.4 Extendability
R> An NSIS protocol must provide means to enhance a 
R> protocol with future procedures, messages, parameters 
R> and parameter settings.
G> Maybe this requirement could be a part of the modularity 
G> requirement 5.1.3!

No. This requirement says that coding space and rules must 
enable a modular build up of the NSIS protocol. It's not 
about more lightweight, its about more advanced.
Maybe we should remove "lightweight" and "extendable" and
concentrate on the requirement for a coding space and coding
rules which must enable a modular build up of the NSIS 
protocol, sub- and supersets of it.

R> 5.12.6 Reliable Communication
R> NSIS signaling procedures, connectivity between units 
R> involved in NSIS signaling as well as the basic 
R> transport protocol used by NSIS must provide a maximum 
R> of communication reliability. Procedures must define 
R> how an NSIS signaling systems behaves if some 
R> kind of request it sent stays without 
R> answer (this could require e.g. be timers, 
R> number of message retransmits and release messages). 
R> An NSIS signaling unit must be able to check its connectivity 
R> to an adjacent NSIS signaling unit at any time (this requirement 
R> must however not result in a DoS attack tool - the frequency 
R> of these checks must be limited, and flow control may be useful). 
R> The basic transport protocol to be used between adjacent 
R> NSIS units must ensure message integrity and reliable transport.
G> I think that this requirement is embedded into Section 5.8.

5.8. is about security. 5.12.6 is about reliability in 
communication. The aim of a reliable protocol design 
is to prevent a node from keeping stale state.

R> 5.12.7 Smooth breakdown
R> A unit participating in NSIS signaling must no cause further 
R> damage to other systems involved in NSIS signaling when it 
R> has to go out of service.
G> Is this a NSIS protocol requirement?

Yes. As all other parts of protocol design influencing operational
stability. A signaling node being able to say "hello" to other 
signaling nodes may as well be enabled to say "good bye".

Regards, Rüdiger

---

From: "Georgios Karagiannis (ELN)" <[email-masked]>
Date: Thu, 2 May 2002 17:35:07 +0200

Hi Rudiger

R> In my view designing protocols which may operate 
R> stable is an activity starting with protocol design.  

I agree with you, but such issues are already included in other parts
of the requirements draft!
My comment was related to the sentence:
"The state of a unit involved into NSIS signaling must 
be stable no matter what the surrounding conditions are."
I see this as an implementation issue!

 

R>> 5.3.4 refers to behaviour in the case of problems in the data
R>> plane. My suggestion here is about unexpected events/errors
R>> in the control plane. If you think that this point carries
R>> to many details, let's split it up in several individual
R>> requirements.

Section 5.3.4 does not specify if the errors are in the data plane or control 
plane!

[R]>> Reworded 5.12.3 Default behaviour
[R]>> An NSIS protocol must define default behaviours and parameter 
[R]>> settings wherever NSIS allows for a set of options.

[R]>> This is a basic state of the art signaling design paradigm. 
[R]>> It is not service specific. 

Could you please give an example!!
 
R> 5.12.4 Extendability

[R]>> No. This requirement says that coding space and rules must 
[R]>> enable a modular build up of the NSIS protocol. It's not 
[R]>> about more lightweight, its about more advanced.
[R]>> Maybe we should remove "lightweight" and "extendable" and
[R]>> concentrate on the requirement for a coding space and coding
[R]>> rules which must enable a modular build up of the NSIS 
[R]>> protocol, sub- and supersets of it.

I do not agree on removing the term lightweight!

[R]>> 5.8. is about security. 5.12.6 is about reliability in 
[R]>> communication. The aim of a reliable protocol design 
[R]>> is to prevent a node from keeping stale state.

Well message integrity is included in Section 5.8.
Regarding the other part of reliability, maybe Marcus could give a 
better answer!

[R]>> Yes. As all other parts of protocol design influencing 
[R]>> operational stability. A signaling node being able 
[R]>> to say "hello" to other 
[R]>> signaling nodes may as well be enabled to say "good bye".

When a node has an abrupt breakdown, I do not know 
how this breakdown should be made (and required to be) smooth!!
Moreover, there are other requirements such as 5.3.4 and open issue (53)
that partially (or indirectly) solve this issue!

Best regards,
Georgios

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 3 May 2002 12:26:02 +0200

Hello John, hello Georgios,

chapter 5.12 as I proposed it sums up some of "the lessons learned" during the development of other signaling protocols. It's rather generic and certainly not service specific. I've started to work on protocols with ISDN in the early 90s and most of the principles I describe here were applied there. I've later worked on ATM too. Since 1998 I'm working on IP and I specified an "Inter Domain Bandwidth Broker Signaling" together with a couple of other folks for Internet2. Most of the principles I've used to structure these BB codings were taken from RFC3036 (LDP Specification). RFC 3036 is a good example of a state of the art signaling protocol.

If I remember right, taking into account lessons learnt from other protocols was one of the most important aims of NSIS. Maybe I've got a wrong perception what these lessons are. My view is, that if these really basic design principles I've listed are not taken as guidance for the development of NSIS, it may not be very useful. I might be to pessimistic - NSIS may develop a protocol along these guidelines without stating them explicitely.

Georgios gave me a discussion that notification of QoS violation in case of error or failure is related to the handling of  problems in the control plane. I can't follow his conclusion. If the statement is truly is about problems in the control plane and their handling, it's worded rather bad. I'm having more problems with the draft but Marcus announced a review and I wanted to wait for it. Nothing I've suggested as new text is currently in the draft or you need a lot of imagination to find it there. If the requirements are not precise, so will be the solutions based on it.

Regards, Rüdiger

> > compatible with earlier versions of an NSIS protocol.
> 
> I don't support this.  What earlier version of NSIS
> protocols are you talking about?
>  
> > units during unexpected situations. Unexpected situtions are 
> > unknown messages, parameters and parameter settings as well 
> > as receiption of unexpected messages (e.g. a "Reservation 
> > Confirmation" without prior "Reservation Request").
> 
> I think John Postel's words of wisdom are sufficient:
> 'Be generous in what you recieve and conservative in what
> you send.'
>  
> > 5.12.3 Default behaviour
> > settings wherever applicable. 
> 
> Disagree with this, I don't think we can mandate this at all.
>  
> > 5.12.4 Extendability
> > with future procedures, messages, parameters and parameter settings.
> 
> I don't support the we 'MUST provide means to enhance ..' that is
> too strong.  Extensibility is not a bad thing, but managing 
> this can be
> very difficult
> 
> > signaling unit to discover and remove local stale state. This 
> > may for example be done by means like soft state and periodic 
> > flooding or by a polling mechanism and hard state signaling.
> 
> I am not sure about this either, there are a few things embedded
> in this requirement, and I think this is already covered in other 
> requirements.
>  
> > involved in NSIS signaling as well as the basic transport 
> > protocol used by NSIS must provide a maximum of communication 
> > reliability. Procedures must define how an NSIS signaling 
> > systems behaves if some kind of request it sent stays without 
> > answer (this could require e.g. be timers, number of message 
> > retransmits and release messages). 
> > An NSIS signaling unit must be able to check its connectivity 
> > to an adjacent NSIS signaling unit at any time (this 
> > requirement must however not result in a DoS attack tool - 
> > control may be useful). 
> > The basic transport protocol to be used between adjacent NSIS 
> What is 'maximum reliability' - who should provide this
> function - is it an NSIS protocol, is it the transport protocol
> NSIS runs on top of, is it provided by the network? I don't
> like this requirement.
> 
> > 5.12.7 Smooth breakdown
> > A unit participating in NSIS signaling must no cause further 
> > damage to other systems involved in NSIS signaling when it 
> > has to go out of service.
> 
> I don't think this is a useful requirement.
> 
> John
>

---

From: "Freytsis, Ilya" <[email-masked]>
Date: Mon, 6 May 2002 19:01:04 -0400

Ruediger, Marcus, Georgios and John,

I have finally managed through my mail and would like to add my two cents.

I am not convinced that the new requirement section is needed but I did find
useful some of the proposed requirements. Most of them can be at home in
section 5.1, I believe. I like that every requirement attempts to make a
clear statement what is expected from the protocol. See comments in-line.

Regards,
Ilya 

-----Original Message-----
From: Geib, Ruediger [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 5:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: [NSIS] Operational QoS signaling protocol requirements

Dear Markus,

By and large operational NSIS protocol requirements miss in the requirements
draft. I'd suggest to add:

5.12 Operational Stability
The design of an NSIS protocol must provide a maximum of operational
stability. The state of a unit involved into NSIS signalling must be stable
no matter what the surronding conditions are. This leads to the following
requirements:

5.12.1 Backwards compatibility
A later version of an NSIS protocol must be backwards compatible with
earlier versions of an NSIS protocol.
IF> I like this requirement since it helps prevent design decisions that are
short sighted and may make interoperability of the future version of the
protocol more difficult and painful.

5.12.2 Unexpected situations and error restistance
An NSIS protocol must define behaviour of NSIS signaling units during
unexpected situations. Unexpected situtions are unknown messages, parameters
and parameter settings as well as receiption of unexpected messages (e.g. a
"Reservation Confirmation" without prior "Reservation Request").
IF> Basically you are saying that the state machine behind the protocol
shall be complete (shall describe how react to any received message in any
state). I do not think it is a requirement for NSIS since it is applicable
to any signaling protocol but rather a guideline for the protocol designers.
To be honest I cannot imagine how the NSIS protocol can be designed in any
other way.
5.12.3 Default behaviour
An NSIS protocol must define default behaviours and parameter settings
wherever applicable.
IF> I can make the same comment as above
5.12.4 Extendability
An NSIS protocol must provide means to enhance a protocol with future
procedures, messages, parameters and parameter settings.

5.12.5 Preventation of stale state
An NSIS signalling protocol must provide means for an NSIS signaling unit to
discover and remove local stale state. This may for example be done by means
like soft state and periodic flooding or by a polling mechanism and hard
state signaling.
IF> I tend to agree with John that we have already had a number of
requirements to address this or similar concerns. They may need better
wording and clarification but not a new one.

5.12.6 Reliable Communication
NSIS signaling procedures, connectivity between units involved in NSIS
signaling as well as the basic transport protocol used by NSIS must provide
a maximum of communication reliability. Procedures must define how an NSIS
signaling systems behaves if some kind of request it sent stays without
answer (this could require e.g. be timers, number of message retransmits and
release messages).
An NSIS signaling unit must be able to check its connectivity to an adjacent
NSIS signaling unit at any time (this requirement must however not result in
a DoS attack tool - the frequency of these checks must be limited, and flow
control may be useful).
The basic transport protocol to be used between adjacent NSIS units must
ensure message integrity and reliable transport.
IF> I would rephrase this requirement along the following line:
NSIS protocol must specify procedures that guarantee reliable message
delivery for every transport protocol it may ride on.

5.12.7 Smooth breakdown
A unit participating in NSIS signaling must no cause further damage to other
systems involved in NSIS signaling when it has to go out of service.
IF> I think this one is a subset of 5.12.2. If 5.12.2 is achieved than NSIS
signaling entity whether it breaks down smoothly or not will bring no damage
to others.

Regards, Rüdiger

Rüdiger Geib
Senior Expert
T-Systems Nova GmbH
Technologiezentrum