Subject: Change in Cisco implementation of ZLB ack. after ICCN

From: "Jesper Koed \(JK\)" <[email-masked]>
Date: Tue, 1 May 2001 14:54:36 +0200

Hi

When the L2TP session is established the LNS sends an ZLB to ack. the ICCN
send by the LAC.
The LNS is a Cisco 2621 router running IOS 12.0(7)T. When using this version
the ZLB ack. (of the ICCN)
holds the session number of the session just established.
After upgrade to IOS 12.1T (and newer) the ZLB ack. (of the ICCN) has a now
zero in the session number.
I have been using the session number in the ZLB ack. as a unique ref. to an
s/e machine in our own L2TP implementation.
I can not find any thing in the RFC either for or against a session number
in the ZLB ack.

Q: Does anybody know the reason for setting the session number to zero in
the ZLB acknowledge (of the ICCN) in the new IOS version ?

I may have missed something in the RFC, or the IOS implementation is altered
for some reason.

Regards
Jesper Koed
Systems Software Engineer

Thrane & Thrane
Lundtoftegårdsvej 93D, DK-2800 Lyngby, Denmark
Direct:	+45 39 55 89 90
Reception:	+45 39 55 88 00
Fax:	+45 39 55 88 88
E-mail: 	[email-masked]
Internet:	http://www.tt.dk/

---

From: [email-masked]
Date: Tue, 01 May 2001 07:51:55 -0700

Greetings,

> I may have missed something in the RFC, or the IOS implementation is altered

This went around the list awhile ago. Since a ZLB is part of the control
channel, and not part of a session nor tunnel, the session and tunnel
should both be zero. I couldn't find this explicitly stated in RFC2661
though.

As for the IOS implementation, I would assume (I don't work on it, thus
I don't know) that someone was just cleaning up some code.

-- 
Kyle A. York
Sr. Subordinate Grunt

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 01 May 2001 09:58:37 -0700

> zero in the session number.

That was a bug, not a feature. Sorry that it has caused you grief. The
ZLB is a control channel message which should have no relation to a
particular session. It is possible that you will not even receive a ZLB
for every ICCN. That is, if you are bringing up a lot of sessions, we
may ack several messages as a group rather than sending a ZLB ack for
every ICCN. I hope that this, at least, is clear in the RFC.

- Mark

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 01 May 2001 10:20:37 -0700

>should both be zero. I couldn't find this explicitly stated in RFC2661

If IOS is setting tunnel ID to 0 in the header of a ZLB, then IOS is not
RFC2661-compatible. I'm sure Mark would not allow that. :-)
From RFC2661, bottom of page 23 and top of page 24:

  "The Assigned Tunnel ID AVP establishes a value used to multiplex
   and demultiplex multiple tunnels between the LNS and LAC. The L2TP
   peer MUST place this value in the Tunnel ID header field of all
   control and data messages that it subsequently transmits over the
   associated tunnel.  Before the Assigned Tunnel ID AVP is received
   from a peer, messages MUST be sent to that peer with a Tunnel ID
   value of 0 in the header of all control messages."

This section is very clear: once you receive an Assigned Tunnel ID AVP,
all messages (data _AND_ control) sent to the peer must have this value
in the Tunnel ID field on the header. Note the 'MUST's.

The session ID of a ZLB is irrelevant because ZLBs are not associated
with any given session.

It sounds to me like Jesper has assumed (incorrectly) that L2TP mandates
some sort of lock-step sequence with a ZLB which is not true. The following
sequence is perfectly valid (assuming default values as indicated
in RFC2661):

       LAC                LNS
      SCCRQ         ->
                    <-   SCCRP
      SCCN          ->
                    <-   (optional ZLB)
      ICRQ (sess 1) ->
      ICRQ (sess 2) ->
      ICRQ (sess 3) ->
                    <-   (if you didn't send a ZLB until now, one is now
                          required since there are 4 unacked messages)
                    <- OCRQ (sess 4)
     (optional ZLB) ->
                    <- ICRP (sess 3)
                    <- ICRP (sess 1)
     OCRP (sess 4)  ->          (this may ack the previous three messages)
                    <-   (optional ZLB)
                    <- ICRP (sess 2)   (this may ack the previous message)
     ICCN (sess 3)  ->
                    <-   (optional ZLB)
     ICCN (sess 2)  ->
     OCCN (sess 4)  ->
     ICCN (sess 1)  ->
                    <-   (if you didn't send a ZLB until now, one is now
                          required since there are 4 unacked messages)

Notice how the messages for each session (call) are interleaved with other
messages. Each session runs an independent sequence of ICRQ, ICRP, ICCN
(or OCRQ, OCRP, OCCN). ZLBs just carry acks for the control channel, not
for a given session, but for the whole tunnel.

BTW, the sequence above is very typical on high density systems.

---

From: Wei Luo <[email-masked]>
Date: Tue, 01 May 2001 10:42:13 -0700

>RFC2661-compatible. I'm sure Mark would not allow that. :-)

That's a wrong "if", however.  Suppose any vendor sets tunnel ID to 0 in 
the ZLB, it's going to be discarded by the peer, causing retransmission, 
when retrans exceeds a threshold, your tunnel is quite likely to be torn down.

---Wei

---

From: [email-masked]
Date: Tue, 01 May 2001 11:02:53 -0700

Greetings,

> in the Tunnel ID field on the header. Note the 'MUST's.

Yes, sorry. I blew it. The control channel is of course tied to the
tunnel, but NOT the session.

-- 
Kyle A. York
Sr. Subordinate Grunt

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 01 May 2001 11:19:34 -0700

>when retrans exceeds a threshold, your tunnel is quite likely to be torn down.

I'm sorry if my statement was misinterpreted: I'm sure IOS wouldn't set
the Tunnel ID to 0 on ZLBs because, as you very well point out, it would
cause a lot of trouble. I should have worded that better.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 01 May 2001 11:20:25 -0700

> > RFC2661-compatible. I'm sure Mark would not allow that. :-)

Yes, we certainly do set the tunnel ID for all control messages. It's
just the session ID that is now 0.

- Mark