GlassFish - World's first Java EE 7 Application Server


Document: Multihome support
Reviewer: Sreeram
Review date: 3rd Feb 2009
Response date: Document updated with feedback on 1 March 2009

Comments :

  • Look at Sections 14.2 and 14.2.1 for info on MH support scenarios and how they are exposed to applications. We need to expose the list of outbound interfaces in single instance or clustered setups to applications vis a ServletContext method. Seems like they have setOutboundInterface on a SipSession (which I thought was crazy enough..) and so we need to remember this in SSR. This has to be used for further outbound messages that involve this session. Should we store the listener name instead of ip address?
  • There are wrinkles wrt to Application Router which I failed to understand.
  • Fold in the discussion from the CLB upgrade spec. I think there is little in that document other than saying that we need a way to mark an interface as private. If one or more interfaces is marked private then CLB would use only those interface(s) for BE traffic. I guess the default disposition is public for all interfaces.
  • reading kristoffer's doc, the impression I got was that he is thinking of some general QoS capability like gold/silver marking on all listeners. So the program cal get hold of the gold class listeners etc. I dont know how they would programmatically request a list of such interfaces only, in a portable way. Towards the end of the doc, he does say that this is going beyond the spec.
  • we need 2 or 3 reference network topologies that we will test and support. Can you put that in design doc.
  • also, just for documentation purposes, can you clearly write down what happens today when there are multiple interfaces on a computer and we have one listener configured on 0.0.0.0:5060. We talked today about some platform specific behaviors.

Response :

Thanks for the feedback, i will work with Sony for the design doc of network topologies. Will also update the documentation with what (points) we had discussed in the meeting yesterday.
Document updated with feedback on 1 March 2009

Document: Multihome support
Reviewer: Kshitiz
Review date: 10th March
Response date: 10th March

Comments :

1 For internally proxied SIP request and outgoing SIP request, a VIA is added with local address. In multihome scenario which one should be used. Will this be a configurable as well?
2. Shall we mention HTTP/SIP requests received on IPv6 can be proxied on IPv4 address?
3. Shall we capture that FE Layers can be disabled on internal listeners?

Response

> 1 For internally proxied SIP request and outgoing SIP request, a VIA is added with local address. In multihome scenario which one should be used. Will this be a configurable as well?
For internal SIP requests we can use the address that is being used to send the message. For outgoing ones we should use the outbound interface that is configured in the message or the default external address (VIP/HLB).
> 2. Shall we mention HTTP/SIP requests received on IPv6 can be proxied on IPv4 address?
We can do this, but i dont know if QE will commit to test this ...
> 3. Shall we capture that FE Layers can be disabled on internal listeners?
>
OK, i guess this is an optimization at runtime, there is no way to do this through configuration because the stack-config is per container and not per-listener.

IPv6support / dualstack discussion (Jan/FEb 2009)

Hi

The AP does not perform any modification of the proxy headers to avoid
CLB on the XDMS, the reason is that the AP is "usually" not colocated
with the XDMS in the same node and when sending the request to another
node we want the XDMS to perform CLB.
Also using an "IP spreader" in front of XDMS there is no guarantee that
when the request enters the XDMS it will end up on the same processor as
the AP.
This means of course that if the AP is colocated with the XDMS then CLB
will be perfomrmed twice, first time when the request enters the AP and
second time when the request enters the XDMS. But we have not found this
to be sufficiently "bad" to try to do "internal" forwarding between AP
and XDMS if colocated.

When AP performs SSO authentication based on the clients "source IP
address" the address is sometimes read from the socket (IP v4) and
sometimes from an internal header added by the CLB frontend processor
(who see the clients actual IP address) depending on if the ip-spreader
happened to send the request to the users TP in the first try or not.
The IP address is sent to the HSS over Zx/Diameter and I think it only
accepts IPv4 addresses for authentication.
The Diameter stack has their own java sockets for communication and I
dont know if they support Ipv6, maybe they can run on a separate Ipv4
net?

Incoming HTTP requests are through the ServletAPI and Tomcat/Coyote
classes, outgoing HTTP (towards XDMS) uses the
Java.net.URL/HttpUrlConnection classes.

BR
/Johan N.

Hi Lars,

> > Lars: It means it will call another application (same or different
> > instance)or even outside the cluster since the AP serves XCAP traffic
> > to all applications in an IMS network. It does it over XCAP (HTTP).
> > What the AP does is to take the request do an authentication towards
> > the HSS and then try to locate the XDMS instance for this specific
> > user. The XDMS is another application. So the AP will send the request

> > to this application after changing some of the headers of the incoming
request.
> > Maybe forwarding the HTTP request is more correct to say.
> > AS I remember the AP has some list of XDMS instances(guess as
> > FQDNs)and tries this list.
Please ensure that when the request is forwarded to another instances
(*inside the cluster, to an XDMS application that is configured for load
balancing*) the proxy* header have to be modified (or preserved)
accordingly, The proxy* headers are used by the http clb to convey
certain information from FE to BE. So when the forwarded request reaches
the backend (XDMS), then if the proxy* headers are missing (or wrong)
then it might cause it to be proxied (clb) again based on the configured
rules (if the XDMS application is configured for load balancing). So,
could you please confirm this. The outgoing requests (through the AP
using the HttpUrlConnection) are not intercepted at the host (Source)
instance by the clb, so it cannot modify the headers. And this request
when it reaches the XDMS (forwarded) instance would be treated like any
other http request and might cause the DCR rules to be applied on it
which would result in it being forwarded to the relevant backend.

> > Lars: Is there a problem with this? I see it as this is what normally
> > should be done. What I earlier wanted to say with that was that it was

> > no req that everything inside the cluster is IPv6. And that the XDMS:s

> > (other applications use IPv4)
> >
No there is no problem, it is just that we have to account for this
behavior in the one-pager and the implementation.

Thanks
-Ramesh

Lars Andersson A wrote:
>
> Hi Lars,
> Thanks for the very detailed email. I gather the following points
> from this.
>
> 1. Dual-stack requirement is for Http only.
> 2. Http clients would connect to SailFin FE through IPv4 or IPv6
> (depending on the clients and how they are configured).
> 3. There will be only one Http listener that will be configured in
> IPv6, (with an equivalent mapped IPv4 address for IPv4 clients to

connect to).
> 4. If the FE receives traffic on IPv6 then it has to be proxied to BE
> on IPv6. We cannot assume that the FE-BE traffic will always be onlyIPv4 .
> >
> > I think we made this assumption in the FE-BE/Multihome one-pager
> > because of the following lines in the requirement "Cluster internal
> > traffic can use IPv4" and " Internal XCAP traffic will be using IPv4"
> > Lars: Is there a problem with this? I see it as this is what normally
> > should be done. What I earlier wanted to say with that was that it was
> > no req that everything inside the cluster is IPv6. And that the XDMS:s

> > (other applications use IPv4) 5.
> >
>> >> The AP will however use IPv4 when sending (proxying) the traffic
>> >> onwards to the XDMS (seen as another application on the Application
>> >> server or other AS).
>> >>
> > I did not understand the what AP (which is an application deployed in
> > SailFin) proxying means ? Does this mean it will make a database
> > connection with XDMS and that connection will be IPv4 or does it mean
> > that it will call another application in the server (same or different

> > instance). I assume this is different from the FE-BE proxying (which

> > is based on DCR rules) !
> > Lars: It means it will call another application (same or different
> > instance)or even outside the cluster since the AP serves XCAP traffic
> > to all applications in an IMS network. It does it over XCAP (HTTP).
> > What the AP does is to take the request do an authentication towards
> > the HSS and then try to locate the XDMS instance for this specific
> > user. The XDMS is another application. So the AP will send the request

> > to this application after changing some of the headers of the incoming
request.
> > Maybe forwarding the HTTP request is more correct to say.
> > AS I remember the AP has some list of XDMS instances(guess as
> > FQDNs)and tries this list.
> >
> > 6. Testing this would involve configuring the system with dual stack
> > support.
> > 7. Supporting IPv6 for SIP is not a requirement but a "nice to have".
> > Yes. Have you seen this from other customers?
> >
> > Thanks
> > -Ramesh
> >
> > Lars Andersson A wrote:
> >
>> >> Hello
>> >> This requirement is only valid for HTTP since in our IMS solution the

>> >> SIP traffic will be IPv4. IPv6 to IPv4 transformation for SIP will be

>> >> handled by IMS core before coming up to the AS. That is the minimum.
>> >>
>> >> The AP (Aggregation proxy) an application within PGM will receive
>> >> XCAP
>> >>
> >
> >
>> >> traffic(based on HTTP) which is IPv6.
>> >> Each UA acessing the AP is as I see it only IPv4 or IPv6. IPv6 then
>> >> beeing a mobile terminal but I guess there could also be other UA:s
>> >> (fixed) which might use IPv4.
>> >> I do not think that PGM and for this case specifically the AP will
>> >> have two listeners.
>> >>
>> >>
>> >> What the AP does is basically to authenticate the user (done using
>> >> Diameter (using TCP) towards HSS using IPv4) and then redirecting the

>> >> traffic towards the backend database(XDMS)in which some modification
>> >> or read should be done.
>> >>
>> >> The AP is currently using CLB.
>> >> Not that it is specifically user centric as such but there are some
>> >> caching that makes the behaviour better when using data centric.
>> >> (this
>> >>
> >
> >
>> >> what I was trying to find out earlier from PGM) So should we not
>> >> proxy
>> >>
> >
> >
>> >> the request onwards using IPv6 to the packend hosting the AP? (FE-BE)
>> >>
>> >> The AP will however use IPv4 when sending (proxying) the traffic
>> >> onwards to the XDMS (seen as another application on the Application
>> >> server or other AS).
>> >> Here I guess it would be good to separate this traffic onto a
>> >> differnt
>> >>
> >
> >
>> >> network since the AP is doing authentication (for security reasons
>> >> then) but when asking they do not do that today and do not have it as
>> >>
> > a req.
> >
>> >> I guess I should update the requirement a bit.
>> >> And I guess you are rigth that it might mainly be a configuration
>> >>
> > issue.
> >
>> >> As I have understood it we are supporting and as such supported. But

>> >> as I understood it earlier this was not tested in SGCS 1.5.
>> >>
>> >> When it comes to the RFC I have not been able too look at that one
>> >>
> > yet.
> >
>> >> What is the affect if we do not support it and is it relevant for us
>> >> since we are here talking about HTTP?
>> >> However if we would like to get IPv6 for the SIP parts I guess we
>> >> should include it. That is then not a req from our side since we are
>> >> solving this issue on an IMS solution level for SIP but guess it
>> >> could
>> >>
> >
> >
>> >> be valuable for sailfin as such.
>> >> When it comes to IPv6 we have been talking about it for 5 years I
>> >> think and now finally we are going to do at least tests in china.
>> >> (They are running out of addresses for their mobiles as I understand
>> >> it)
>> >>
>> >>
>>
>> >> Hi Lars,
>> >> Could you please clarify the following points w.r.t Ipv6
>> >> requirement.
>> >>
>> >> > SGCS shall support an IPv6/IPv4 dual stack making it possible to
>> >> accept traffic from an IPv6 or IPv4 network simultaneously.
>> >>
>> >> Does this mean that there will be 2 different listeners one
>> >> configured
>> >>
> >
> >
>> >> with an IPv4 address and the other with an IPv6 address, and the
>> >> traffic from both has to be handled. Would this not be one of the
>> >> multihome use cases then.
>> >> Or does "dual stack" mean the following .
>> >> A listener configured on IPv6 (or IPv4 ) should be able to send and
>> >> receive traffic to/from both Ipv4 and Ipv6 UAs. In which case can we
>> >> assume that the DNS will be populated with both IPv4 and IPv6
>> >> addresses (A and AAAA entries) corresponding to the same fully
>> >> qualified domain name of the host. Will this not be a OS related
>> >> configuration then ( to configure the v6 address). Is the change in
>> >> SailFIn restricted to the DNS layer alone (if any). If the UA is also

>> >> a dual-stack system, then should we have a policy which dictates
>> >> which
>> >>
> >
> >
>> >> version (6 or 4) to use while communicating or should we leave this
>> >> to
>> >>
> >
> >
>> >> whatever the DNS lookup returns.
>> >>
>> >>
>> >>
>> >> > Cluster internal traffic can use IPv4.
>> >> Is this FE-BE traffic and the GMS traffic ? Can we assume that FE-BE
>> >> traffic (or internal listeners) will always be Ipv4.
>> >>
>> >> > The motivation behind this requirement is that PGM has a component

>> called aggregation Proxy which will have IPv6 based traffic (XCAP)
>> even if the SIP and DNS traffic will be using IPv4. Internal XCAP
>> traffic will be using IPv4.
>>
>> Is the dual stack requirement only for SIP or for both SIP and HTTP ?
>>
>> Also, Is there a need for supporting this Ipv6 formatting related
>> draft ?
>> http://tools.ietf.org/html/draft-ietf-sip-ipv6-abnf-fix-03
>>
>> Thanks
>> -Ramesh
>>

Minutes from meeting discussion (Lars, Sankara, Ramesh, Kshitiz)

105 65-0192/03385 - SCAS: IPv6/IPv4 Dual Stack Support Have

Lars ; As we stated it should be more of a testing activity.
HTTP clients should be able to use either IPv4 or IPv6. There is no
specific requirement on if IPv4 or IPv6 should be used between FE and BE
as I see it. But to me it seems natural that we do that part over IPv6.
We should try to outline how this should be tested. I will send another
mail with this.

Document: Multihome support
Reviewer: Joe Fialli
Review date:13 March 2009
Response date:

First of all, the section that states the changes in Sailfin for supporting ipv6 is quite helpful for me
to look at shoal/gms/jxta and make sure it is following these general programming guidelines.
I know that the gms bind interface address was currently only tested with literal ipv4 addressing, since
that was all I understood.

It is quite challenging to understand the differences between IPv4 and IPv6 addressing. It seems quite easy
for users to enter the incorrect format into domain.xml in all places that an address can be entered.
There are literal IPv4 addresses (which is what is in domain.xml now), mapped IPv4 addresses (that are
legal with IPv6), IPv6 network interface names, IPv6 addresses( with ":" in them).

Lastly, if two subsystems happen to choose same network address, port, the application server fails to come up
and we have a collision. That has been worked through with IPv4 only addressing, it seems all networking changes
needed to accomodate dual-stack in various subsystems may reintroduce these past problems. It is a risk that
should be explicitly mentioned.

The "Reference network diagram", Figure 2, should be its own subsection. I missed the key
statement that this was going to be the configuration that would be used to validate multihome support.
Is it correct to state it will be the only configuration tested for multihome? It is quite useful to state this
since there are so many endless configuration possiblitilies.

Also, could you explain the difference between IPv4_1 on network interface eth0 and IPv4_2
on network interface eth1 in Figure 2?