The section 7.4 'UDP Tunneling' does not say anything about retransmissions. This may lead to implementations that are either suboptimal in bandwidth consumption or incompatible.

Resolution:
Give recommendations about retransmission policy similar to TCP's NewReno-SACK.

Revised text:

Add a new subsection 'Retransmission Policy' before the subsection 7.4.2 'Fragmentation':

Retransmissions in UDP Tunneling Protocol SHOULD be controled by a policy based on an estimate for the Round Trip Time (RTT) such as NewReno-SACK in TCP [RFC nnnn]. The Retransmission TimeOut (RTO) MUST be at least the estimated RTT.

Add the following note at the end of subsection 7.4.6 'Resume':

Note: The Resume chunk SHOULD be included in each UTP message until the sender has received an acknowledgement for a message containing a Resume chunk.

No Data Available

Usage of sequence numbers in UDP Tunneling Protocol messages in section 7.4 needs refinements.
We have found the following two problems:
1) If the first sequence number is arbitrary, then the receiver must examine the playload before it can detect whether or not the beginning of the message sequence is received.
2) If UTP messages containing only Acknowledge chunck are acknowledged, then we will have an infinite loop of ackning acks.

Resolution:
1) Start sequence numbers always from 0x0001.
2) Reserve sequence number 0x0000 for UTP messages that are not to be acknowledged (messages that only contain Acknowledge and/or Pause chunk).

Received text:
Add a new subsection 'Sequence Numberging' after the subsection 7.4.1 'UDP Tunneling Protocol':

Each communication session must start sequence numbering from 0x0001. In other words the UTP message containing the InitialAccessRequest chunk (or its first fragment) and the associated reply containing the InitialAccessReply chunk (or its first fragment) MUST have UTP Sequence Number 0x0001.

The sequence number counting follows the usual modulo arithmetic with the exception that the sequence number 0x0001 follows the sequence number 0xFFFF.

The UTP Sequence Number 0x0000 is reserved for UTP messages that only contain the Acknowledge chunk and/or the Pause chunk. These messages MUST NOT be acknowledged.

Add the following note at the end of subsections 7.4.3 'InitialAccessRequest' and 7.4.4 'InitialAccessReply':

Note: UTP message containing this chunk (or its first fragment) MUST have sequence number 0x0001.

Add the following two notes at the end of subsection 7.4.5 'Pause':

Note 1: If the UTP message contains only the Pause chunk (with or without the Acknowledge chunk), then the UTP Sequence Number MUST be 0x0000. The receiver SHOULD NOT acknowledge such a message.

Note 2: After sending the Pause chunk, the sender SHOULD reply to each arriving message by a UTP message containing the Pause chunk. The UTP message MAY also contain ACknowledge and/or GTPData chunks.

Add the following note at the end of subsection 7.4.7 'Acknowledge':

Note: If the UTP message contains only the Acknowledge chunk (with or without the Pause chunk), then the UTP Sequence Number MUST be 0x0000. The receiver SHOULD NOT acknowledge such a message.

No Data Available

There is no way in the current specification to gracefully close a communication session. This is not a problem, but may complicate recovery from communication failures.

Resolution: Add CloseRequest, CloseReply and CloseIndication chunks. CloseRequest/CloseReply pair of chunks allows negotiated closing of the UTP communication session. CloseIndition chunk allows a bridge to inform its peer bridge that it is going to close the UTP communication session.

Revised text:
Add the following three descriptions of UTP chunks at the end of subsection 7.4.1 'UDP Tunneling Protocol':
7. CloseRequest: sent by the Terminal or Access Bridge. No Flags, Lenght, and Value field.
8. CloseReply: sent by the Terminal or Access Bridge. No Flags, Lenght, and Value field.
9. CloseIndication: sent by the Terminal or Access Bridge. No Flags, Lenght, and Value field.

Add the following three subsections at the end of section 7.4 'UDP Tunneling':

Close Request

The chunk Type is 0x07. The chunk does not have any other fields.

The chunk can be sent either by the Terminal Bridge or by the Access Bridge.

The bridge sends this chunk when it wants to close the communication session. After sending this chunk the bridge mwaits for the UTP message cointaining the CloseReply chunk. The bridge sending the CloseRequest chunk MUST process and acknowledge all UTP messages until receiving the CloseReply chunk.

When a bridge receives the CloseRequest chunk, it SHOULD immediately retransmit all unacknowledged UTP messages as well as all remaining GTP messages before sending the CloseReply chunk.

CloseReply

The chunk Type is 0x08. The chunk does not have any other fields.

The chunk can be sent either by the Terminal Bridge or by the Access Bridge in response to the CloseRequest chunk.

The bridge receiving the CloseRequest chunk SHOULD NOT send the CloseReply chunk before all other UTP messages have been acknowledgeged. After sending the CloseReply chunk, the bridge SHOULD wait for the acknowledgement before releasing all data structures associated with the UTP communication session.

The bridge receiving the CloseReply chunk SHOULD acknowledge the UTP message containing the CloseReply chunk by a UTP message having sequence number 0x0000. After sending this reply the bridge can release all data structures associated to the UTP communication session.

If a bridge receives CloseReply chunk, but it has not send the CloseRequest chunk, the bridge SHOULD send the CloseIndication chunk. See section 7.4.n 'CloseIndication'.

CloseIndication

The chunk Type is 0x09. The chunk does not have any other fields.

The chunk can be sent either by the Terminal Bridge or by the Access Bridge.

The bridge send this chunk to inform the peer bridge that it will close the communication session. The bridge MAY wait for the acknowledgement of the UTP message containing the CloseIndication chunk. In this case the bridge SHOULD discard all arriving UTP messages and response by retransmitting the UTP message containing the CloseIndication chunk. However, the bridge does not need to wait for the acknowledgement of the UTP message containing the CloseIndication chunk. It can immediately, after sending the CloseIndication chunk, release all data structures related to this communication session and stop accepting messages to the UDP port.

When the peer bridge receives the CloseIndication chunk, it SHOULD immediately acknowledge that UTP message and stop using the UDP end-point of the peer bridge. After sending the acknowledgement, the bridge SHOULD release all data structures related to the UTP communication session.

No Data Available

Currently gtp_from_terminal has no raisable exceptions. But it might
happen that the Access Bridge has already forgotten the terminal. In
this case it should communicate this to the invoker by raising an
exception (UnknownTerminalId would be suitable). The invoker can then
send a GTPForwardReply with the status FORWARD_ERROR_UNKNOWN_SENDER.

see above

GTPForwardReply needs to be forwardable

Currently GTPForwardReply (section 7.2.18) is marked not forwardable.
But if there have been outstanding GTPForward messages when handoff
happens, these messages cannot then be acknowledged. This situation
is similar to the one with OpenConnection where OpenConnectionReply is
forwardable, the reason being that outstanding requests can be
responded to after handoff. For the same reason, GTPForwardReply
should also be forwardable.

Make GTPForwardReply forwardable

Chapter 3.1.1.
In paragraphs 2, 3, and wording "returning the object reference of the
Access Bridge" is not precise enough. Instead we should say "returning the
Mobile IOR indicating the Access Bridge".
3rd paragraph, line 4: replace "replies" by "should reply"
4th paragraph, line 3: replace "will reply" by "should reply"

Chapter 3.2.1 IDL of ProfileBody
add space between TerminalObjectKey and teminal_object_key

Page 3-4, 2nd paragraph, line 3: replace "MobileTermial" by "MobileTerminal"

Page 4-2, 1st line: remove "," after "new_access_bridge"

Pages 4-2 and 4-3: replace "UnknownTermialID" by "UnknownTerminalId" (four
times)

Chapter 7.2
Add at the bottom of page 7-2 paragraph: All timeout values are in seconds.

Page 7-5: replace "MobileTeriminal" by "MobileTerminal" (two times)

Page 7-5, last paragraph: The last two line should read as:
"then a handoff procedure or the access recovery procedure as described in
Section 8.2, "Network Initiated Handoff", in Section 8.3, "Terminal
Initiated Handoff", or in Section 8.4, "Access Recovery", is carried out.

Page 7-10, first line: replace
"MobileTerminal::AccessBridgeTransportAddress" by
MobileTerminal::AccessBridgeTransportAddressList"

Page 7-15, second bullet: replace "CLOSE_REASON_RRESOURCE_CONSTRAINT" by
"CLOSE_REASON_RESOURCE_CONSTRAINT"

Page 7-15, third bullet: replace "CLOSE_REASON_RIDLE_CLOSED" by
"CLOSE_REASON_IDLE_CLOSED"

Page 7-15, fourth bullet: replace "CLOSE_REASON_RTIME_TO_LIVE_EXPIRED" by
"CLOSE_REASON_TIME_TO_LIVE_EXPIRED"

Chapter 7.2.17, paret Description, 2nd paragraph: replace "gtp_from
terminal" by gtp_from_terminal"

Chapter 7.5.1, 2nd paragraph: replcae "transmission of unreliable" by
"unreliable transmission"

Chapter 7.5.3, 1st paragraph: add "CDR encapsulation of" at the end of
paragraph

Figure 8-1: replace "location_update" by "update_location"

Chapter 8.3.1, numbered item 5: replace "ReleaseTunnelReuqest" by
"ReleaseTunnelRequest"

Chapter 8.3.2, numbered item 2: replace "location_update" by
"update_location" and "operation" not in bold

Figure 8-2 and 8-3: replace "location_update" by "update_location"

Chapter 8.5, last paragraph, 1st line: replace "an old Access," by "an old
Access Bridge,"

The following editorial changes should be implemented:

The OpenConnectionRequest in section 7.2.10 contains the target object
reference. Since, in case of GIOP 1.0 or 1.1 clients, the Access
Bridge may have only the object key, the note permits the Access
Bridge to use GIOP::TargetAddress as this object reference. I request
that, for consistency and simplicity of implementation, the target
object reference in this message were always given as
GIOP::TargetAddress, in both directions.

The target object reference in the OpenConnectionRequest message to be of type GIOP::TargetAddress.

When a terminal loses connection to its current Access Bridge, section
4.1 says that the Access Bridge deregisters the terminal by invoking
update_location at the Home Location Agent giving NIL as the new
Access Bridge reference. Assume now that the terminal is performing
an access recovery to a new Access Bridge. It may happen that the new
Access Bridge invokes update_location, then the old Access Bridge, not
yet knowing about the recovery in progress, deregisters the terminal
and only after that the new Access Bridge invokes recovery_request at
the old Access Bridge. This sequence of events leaves the Home
Location Agent to believe mistakenly that the terminal does not have
an associated Access Bridge.

A possible solution: Add a deregister() operation to the
HomeLocationAgent interface. This operation would take as parameters
the terminal id and the Access Bridge invoking it, and would return a
boolean value. The Home Location Agent could then compare whether the
invoking Access Bridge is the same as the Access Bridge it believes to
be current. If it is, the HLA deregisters the terminal and returns
true, otherwise the HLA does nothing and returns false. Now, from the
return value, the invoking Access Bridge can tell whether there is an
access recovery in progress, and if so, can prepare for it by hanging
on to the terminal's information.

see above

The struct MobileTerminal::ProfileBody contains as its first member
the version number of the profile. However, the specification does
not say what version number is to be used. A clear-seeming solution
would be to use the same version number as for GTP, since GTP is in a
sense this profile's associated protocol.

Specify that MIOR version is the same as the GTP version.

This issue is for Telecom Wireless FTF regarding the current adopted
specification dtc/2001-06-02.

According to current specification, when peer receives GIOPData Message
(7.2.15), it must reply with GIOPDataReply Message (7.2.16). GIOPDataReply
can acknowledge GIOPDataMessage, or indicate one of two failures,
DELIVERY_FAILED_INVALID_CONNECTION_ID or DELIVERY_FAILED_UNKNOWN_REASON.

The issue is, if acknowledgement is already done in GTP level (using the
last_seq_no_received field of GTPHeader) and errors can be expressed with
Error Message (7.2.19), is the GIOPDataReply message superfluous?

This is extremly important issue for us, for we are considering the use of
very narrow band (and expensive) transports.

For example, according the current specification (with the GIOPDataReply),
every non-oneway method invocation requires a minumum of 4 transport level
messages. Here's the message exhance for method invocation:

[ Client ] [ Object ]

client sends
GIOP Request
message:

------- #1 GIOPData -------->

<----- #2 GIOPDataReply -----
includes ack for #1

object sends
GIOP Reply
message.

<------- #3 GIOPData ---------

------ #4 GIOPDataReply ----->
includes ack for #2 and #3

if there's nothing
else to send

<------ #5 IdleSync ----------
ack for #4

However, without GIOPDataMessage the maximum is 3 messages and typical is 2
messages. Here's how:

[ Client ] [ Object ]

client sends
GIOP Request
message:

------- #1 GIOPData -------->

object sends
GIOP Reply
message.

<------- #2 GIOPData --------
includes ack for #2

if there's
nothing else
to send

------ #3 IdleSync ---------->
ack for #2

Conclusion: We suggest that the GIOPDataReply message is removed from
specification and the error code for the use of unknown connection ID
(DELIVERY_FAILED_INVALID_CONNECTION_ID) is introduced to Error message.

see above

In a network initiated handoff (section 8.2) the old Access Bridge is
given a reference to a HandoffCallback object, to which the Access
Bridge reports the status after handoff. However, if the terminal
uses the alternate handoff procedure of section 8.2.5, the status that
the Access Bridge is supposed to report is not specified. There seem
to be two reasonable options:
1) The Access Bridge reports NO_MAKE_BEFORE_BREAK as status
2) The Access Bridge waits for recovery_request and reports success
or failure according to whether recovery happens

It needs to be specified which of these actions the Access Bridge
takes.

see above

In Access Recovery to a new Access Bridge (section 8.4.2) the
invocation of recovery_request at the old Access Bridge is assumed to
succeed. However, it is possible that the old tunnel has been down
for so long that the old Access Bridge has destroyed all information
it has on the terminal. This would make it impossible to fill the out
parameter of recovery_request correctly. I therefore suggest that an
exception to signal a destroyed association (possibly TerminalNotHere)
be added to recovery_request signature and that the new Access
Bridge's actions when receiving this exception be specified.

see above

In the current specification the different conformance options are separated
by version numbers; version 1.0 that does not include hand-off and version
2.o that supports hand-off.

This can be quite confusing and the confusion is likely to multiply in the
event that the whole specification is updated and receives new version
number.

My suggestion is to use similar technique as in CORBA security, where
different conformance levels are separated, not by version numbers, but by
Level numbers.

I suggest that we change "Version 1.0" to "Level 0" and "Version 2.0" to
"Level 1".

see above

In Terminal Initiated Handoff (section 8.3) and Access Recovery
(section 8.4.2) the new Access Bridge needs to invoke different
methods depending on the kind of handoff (step 4 in 8.3.2 and step 5
in 8.4.2.2). However, it is not possible for it to make this
distinction based on the information it has received in previous steps
of the handoff.

Furthermore, in Network Initiated Handoff (section 8.2) the only
distinction for the new Access Bridge is the previous invocation of
transport_address_request. But it is possible that the terminal could
not establish connectivity during the handoff procedure and resorted
to another kind of handoff later. So in this case the new Access
Bridge misidentifies this handoff as network initiated.

The simplest way to correct this seems to be to add an element for
handoff type into RecoveryRequestBody (section 7.2.4). This solution
also looks quite clean.

see above

In opening a connection for GIOP data (sections 7.2.10--7.2.11) the
receiver of a request is responsible for allocating a connection id.
But if two OpenConnectionRequests cross each other, it might be
possible for the same connection id to be allocated to two different
connections. This would completely break at least one, maybe both, of
the connections.

The easiest way to fix this would be to allocate disjoint subsets of
the available connection id space to Terminal and Access Bridges.
Since this is a question of interoperability, the subsets need to be
also mandated. A good one would be for the Access Bridge to use even
numbers and the Terminal Bridge to use odd numbers (excluding the
invalid 0xffffffff).

Access Bridge uses even numbers and Terminal Bridge odd numbers (but not 0xFFFFFFFF).

In the GTP Header (section 7.2.1) there are two unsigned short members
before the byte order flag. Processing this header correctly requires
either processing out of order or possibly correcting already
processed elements afterwards.

I request that the members gtp_msg_type and flags be moved to the
start of the header. This way the header can be processed in order
without the need for backpatching, which is definitely simpler.

see above