Subject: RE: session-id

From: <[email-masked]>
Date: Tue, 22 Apr 2003 18:10:12 +0300

I've added a text proposal to the issue tracker:

Replace:

  "Session Identifier: 
         
  The device identifier is also used as the session
  identifier. This is used for indicating a disconnect
  or session revocation or for charging purposes."

With:

  "Session Identifier:

  Session-Id AVP [DIAMETER] is used as the session
  identifier. This is used for indicating a disconnect
  or session revocation or for charging purposes."

- Dan

> -----Original Message-----
> From: ext Hannes Tschofenig [mailto:[email-masked]]
> Sent: 22 April, 2003 13:31
> To: Forsberg Dan (NRC/Helsinki); [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: session-id
> 
> 
> hi dan,
> 
> thanks for pointing to the diameter session id. sounds good.
> 
> ciao
> 
> hannes
> 
> 
> 
> > -----Original Message-----
> 
> > From: [email-masked] [mailto:[email-masked]]
> 
> > Sent: Dienstag, 22. April 2003 10:43
> 
> > To: [email-masked]; [email-masked];
> 
> > [email-masked]
> 
> > Cc: [email-masked]
> 
> > Subject: RE: session-id
> 
> >
> 
> >
> 
> > There is a ready made solution for this problem, the Diameter
> 
> > Session-Id AVP. It's eternally unique and created by the AAA
> 
> > client (PAA). With this approach the sessions in PANA are subset
> 
> > with the sessions in the AAA (Diameter) backend.
> 
> >
> 
> > See below the description of this AVP from 
> draft-ietf-aaa-diameter-17.txt.
> 
> >
> 
> >
> 
> > 8.8 Session-Id AVP
> 
> >
> 
> > The Session-Id AVP (AVP Code 263) is of type UTF8String and is used
> 
> > to identify a specific session (see section 8). All messages
> 
> > pertaining to a specific session MUST include only one 
> Session-Id AVP
> 
> > and the same value MUST be used throughout the life of a session.
> 
> > When present, the Session-Id SHOULD appear immediately following the
> 
> > Diameter Header (see section 3).
> 
> >
> 
> > The Session-Id MUST be globally and eternally unique, as it is meant
> 
> > to uniquely identify a user session without reference to any other
> 
> > information, and may be needed to correlate historical 
> authentication
> 
> > information with accounting information. The Session-Id includes a
> 
> > mandatory portion and an implementation-defined portion; a
> 
> > recommended format for the implementation-defined portion 
> is outlined
> 
> > below.
> 
> >
> 
> > The Session-Id MUST begin with the sender's identity encoded in the
> 
> > DiameterIdentity type (see section 4.4). The remainder of the
> 
> > Session-Id is delimted by a ";" character, and MAY be any sequence
> 
> > that the client can guarantee to be eternally unique; however, the
> 
> > following format is recommended, (square brackets [] indicate an
> 
> > optional element):
> 
> > <DiameterIdentity>;<high 32 bits>;<low 32 bits>[;<optional value>]
> 
> >
> 
> > <high 32 bits> and <low 32 bits> are decimal representations of the
> 
> > high and low 32 bits of a monotonically increasing 64-bit value. The
> 
> > 64-bit value is rendered in two part to simplify formatting 
> by 32-bit
> 
> > processors. At startup, the high 32 bits of the 64-bit value MAY be
> 
> > initialized to the time, and the low 32 bits MAY be initialized to
> 
> > zero. This will for practical purposes eliminate the possibility of
> 
> > overlapping Session-Ids after a reboot, assuming the reboot process
> 
> > takes longer than a second. Alternatively, an 
> implementation MAY keep
> 
> > track of the increasing value in non-volatile memory.
> 
> >
> 
> > <optional value> is implementation specific but may include 
> a modem's
> 
> > device Id, a layer 2 address, timestamp, etc.
> 
> >
> 
> > Example, in which there is no optional value:
> 
> > accesspoint7.acme.com;1876543210;523
> 
> >
> 
> > Example, in which there is an optional value:
> 
> > accesspoint7.acme.com;1876543210;523;[email-masked]
> 
> >
> 
> > The Session-Id is created by the Diameter application initiating the
> 
> > session, which in most cases is done by the client. Note that a
> 
> > Session-Id MAY be used for both the authorization and accounting
> 
> > commands of a given application.
> 
> >
> 
> >
> 
> >
> 
> > > -----Original Message-----
> 
> > > From: ext Alper Yegin [mailto:[email-masked]]
> 
> > > Sent: 19 April, 2003 02:57
> 
> > > To: Mohan Parthasarathy; Yoshihiro Ohba
> 
> > > Cc: [email-masked]
> 
> > > Subject: Re: session-id
> 
> > >
> 
> > >
> 
> > > > I am not sure I understand the question. I thought the 
> session id
> 
> > > > is used for identifying the session related stuff of a 
> given PaC.
> 
> > > > But this leads to the problem of unique session ids. It might
> 
> > > > be easy if the PAA allocates a session ID (like SPI allocated by
> 
> > > > the receiver) to make it unique across all the PaCs.
> 
> > >
> 
> > > This makes sense. It might even make sense to have an
> 
> > > NAI-like session id,
> 
> > > e.g., [email-masked], if we care about global
> 
> > > identification for
> 
> > > any reason.
> 
> > >
> 
> > > Alper
> 
> > >
> 
> > >
> 
> >
> 
> 
>