Hi Folks, Quick note regarding the Plugtest - I will not be there, but as in previous testing, Ken Morneault and Michael Tuexen will be taking the lead on coordinating the testing and taking notes. I'm sure volunteers to help will be welcome. Cheers and best of luck, L. Ong
Below is a summary of issues / comments raised during the first day of testing at the plugtest: General Issues (apply to SUA/M3UA/M2UA/IUA) ----------------------------------------------------------------------- 1. Do SGPs share AS state? Example: An ASP is Active to two SGPs. If ASP sends ASPIA to one of the SGPs, does the SGP send ASPIA Ack followed by NTFY (AS-Pending) or just ASPIA Ack (since the other SGP has AS state as Active). 2. There is an inconsistency between IUA/M2UA and M3UA/SUA related to whether multiple Interface Identifier/Routing Context (respectively) parameters are allowed in a message. In IUA/M2UA, the message diagrams allow multiple Interface Identifier parameters (there is no text in the docs that discusses this however). M3UA/SUA contain no text related to whether or not this is allowed and there are no diagrams indicating multiple Routing Context parameters in a message. 3. No text that covers the follow case: ASP is UP and has Registered a Routing Key (or Link Key). If ASP then sends ASPUP message again, should SGP transition state back to Inactive, Un-registered? M3UA specific ---------------------- 1. Question about which combinations of parameters are allowed in Registration Request.(Continue reading)
Thanks for the update guys! Hope the Plugtest is going smoothly. Lyndon -----Original Message----- From: Ken Morneault [mailto:kmorneau <at> cisco.com] Sent: Monday, November 04, 2002 9:17 AM To: sigtran <at> ietf.org Subject: [Sigtran] SUA/M3UA/M2UA/IUA Plugtest comments - Day 1 Below is a summary of issues / comments raised during the first day of testing at the plugtest: General Issues (apply to SUA/M3UA/M2UA/IUA) ----------------------------------------------------------------------- 1. Do SGPs share AS state? Example: An ASP is Active to two SGPs. If ASP sends ASPIA to one of the SGPs, does the SGP send ASPIA Ack followed by NTFY (AS-Pending) or just ASPIA Ack (since the other SGP has AS state as Active). 2. There is an inconsistency between IUA/M2UA and M3UA/SUA related to whether multiple Interface Identifier/Routing Context (respectively) parameters are allowed in a message. In IUA/M2UA, the message diagrams allow multiple Interface Identifier parameters (there is no text in the docs that discusses this however). M3UA/SUA contain no text related to whether or not this is allowed and there are no diagrams indicating multiple Routing Context parameters in a message.(Continue reading)
Some comments below..... Tolga > -----Original Message----- > From: Ken Morneault [mailto:kmorneau <at> cisco.com] > Sent: Monday, November 04, 2002 12:17 PM > To: sigtran <at> ietf.org > Subject: [Sigtran] SUA/M3UA/M2UA/IUA Plugtest comments - Day 1 > > > > > Below is a summary of issues / comments raised during the first > day of testing at the plugtest: > > General Issues (apply to SUA/M3UA/M2UA/IUA) > -------------------------------------------------------------- > --------- > > 1. Do SGPs share AS state? Example: An ASP is Active to two SGPs. > If ASP sends ASPIA to one of the SGPs, does the SGP send ASPIA Ack > followed by NTFY (AS-Pending) or just ASPIA Ack (since the other SGP > has AS state as Active). [TOLGA] I think this is quite obvious. AS state machine is per SGP, so NTFY(AS-Pending) is the expected behaviour according to RFC3332. > > 2. There is an inconsistency between IUA/M2UA and M3UA/SUA > related to whether multiple Interface Identifier/Routing Context > (respectively) parameters are allowed in a message. In IUA/M2UA, the(Continue reading)
Hello All, The following are issues encountered during Day 1 of the M2PA plugtest: 1) Management of T7 during remote and processor outage -- consensus is that T7 should be disabled during remote processor outage (to match Q.703). 2) During ALIGNED-READY with local processor outage in-effect, is received User Data and event that should trigger a transition to INS state? (Currently M2PA should not receive user data from SCTP when LPO is in effect. 3) Should M2PA support the processor outage procedure, or should it instead take the link out of service when receiving the LPO primitive from MTP3? 4) Should LSA received during ALIGNED-READY cause a transition to OOS (to match Q.703)? Regards, Jeff
Rohan, Well, the statement is not completely correct. Note that there is no Continue in ANSI: there is a Resume in ANSI which has a similar effect: see Figure 8/T1.111.3 (Sheet 7 of 7). Under the ANSI SDLs one has to receive FISU/MSU (instead of SIPO) before Resume is called to get back to the In Service state. Whereas in ITU, Continue will be latched as a level 3 indication received and the In Service state will occur whenever SIPO ceases. This reveals the absurdity of attempting to rediscribe in M2PA, the MTP2/MTP3 interface which is adequately standardized elsewhere. In these instances M2PA should make reference to Q.703, T1.111.3, or other applicable standard rather than saying what must or must not be done. --brian Rohan Goveas wrote: (Tue, 05 Nov 2002 17:37:50) > > > Hi Brian, Barry, > I feel that the paragrahh of Sec 4.2.4 should be retained as it is instead > of changing it to "If processor outage condition ceases, M2PA shall resume > receiving and transmitting messages". > Recieving of a Level 3 indication ( Flush Buffers/ Continue) is a > necessary condition in addtion to LS processor outage ended to resume > transmitting messages. Doing so will also ensure misssequencing and > duplication of messages at the remote. Please refer Q.703 Figure 8 ( sheet > 13 of 14) - Link sate control diagram, it clearly highlights that MTP L2 has > to wait for a indication from L3 in addition to LS Processor outage ended to > resume traffic.(Continue reading)
Below is a summary of issues / comments raised during the first day of testing at the plugtest: SUA -------- 1. sequence number parameter is mandatory for protocol class 3 in the CORE msg while the data is optional. The sequence number parameter is directly related to the data. If NO data is present(class3), then no sequence number can be provided. If data is present(Class3), then the sequence number must be provided. The note in the spec is not completely clear on this issue. Remove the note(making both optional) or clarify the note via similar text as provided above(clarify the dependency). 2. the implementation note on the sequence of parameters (or rather on the non-sequenced nature of the parameters) is a bit contradicting. If it is truly a set of parameters(meaning not fixed sequence of parameters to occur), then the implementation notes may sometimes contradict each other and imply a certain sequence of parameters. Maybe the note can be removed or changed to "the parameters in a SUA msg should be seen as a set with each parameter only occurring once, with no fixed ordering M3UA --------- 1. The last test case in the test plan shows a scenario in which the ASP does not have NA configured but the SGP does. It indicates the ASP should accept message from SGP with NA but SGP should(Continue reading)
Ken, > 2. Concern about the state of IPSP. With IPSP as single-exchange, > there is an issue related to dynamic registration. General consensus > is that dynamic registration needs to be double-exchange to avoid > potential for race condition. Thus, there is a desire to move back > to double-exchange. [TOLGA] What is exactly the problem scenario? Is the proposal to move just dynamic registration to double exchange or the whole IPSP model?
Pls see comments below. Ken At 01:12 PM 11/4/2002 -0500, Tolga Asveren wrote: >Some comments below..... > > Tolga > >> -----Original Message----- >> From: Ken Morneault [mailto:kmorneau <at> cisco.com] >> Sent: Monday, November 04, 2002 12:17 PM >> To: sigtran <at> ietf.org >> Subject: [Sigtran] SUA/M3UA/M2UA/IUA Plugtest comments - Day 1 >> >> >> >> >> Below is a summary of issues / comments raised during the first >> day of testing at the plugtest: >> >> General Issues (apply to SUA/M3UA/M2UA/IUA) >> -------------------------------------------------------------- >> --------- >> >> 1. Do SGPs share AS state? Example: An ASP is Active to two SGPs. >> If ASP sends ASPIA to one of the SGPs, does the SGP send ASPIA Ack >> followed by NTFY (AS-Pending) or just ASPIA Ack (since the other SGP >> has AS state as Active).(Continue reading)
Some comments below. Tolga > > 6. What should SG do in the following situation: > > > ASP1: SPC 100, RC X > ASP2: SPC 200, RC Y > > ASP1 sends a SCON (APC 100, CPC 200, RC X). Does > SG send a SCON to ASP2. If so, does SG maintain congestion > state? There is no way for SG to audit congestion of ASP1. > > One recommendation: SG sends SCON to ASP2. Maintains > a timer that decreases congestion level every time it triggers. > Further recommendation was to evaluate based on end-to-end > congestion principle in SS7. Need to make sure solution works > equally well for ANSI and ITU. [TOLGA] In such a situation, I wouldn't expect that SCON is sent to ASP2, based on the current RFC3332(because it is sent as reply to an incoming message). But as a lot of people might recall, we had some discussions about the current congestion announcement procedure from ASP to SGP recently. I think, the current approach does not fit M3UA model. Trying to mimic congestion mechanims of MTP3 between SGP and ASP is not the correct approach in my opinion. Congestion should be informed from ASP to SGP, whenever it happens, not as a response to an incoming message. SG controls the SPMC and can decide, whenever to reply with TFC or SCON to a message. I furthermore would prefer a new ASPTM message for it.(Continue reading)
RSS Feed3 | |
|---|---|
1 | |
5 | |
1 | |
3 | |
2 | |
8 | |
6 | |
9 | |
6 | |
2 | |
8 | |
21 | |
16 | |
19 | |
6 | |
2 | |
38 | |
25 | |
20 | |
29 | |
25 | |
28 | |
29 | |
2 | |
2 | |
11 | |
11 | |
16 | |
63 | |
7 | |
6 | |
27 | |
20 | |
27 | |
4 | |
3 | |
55 | |
18 | |
5 | |
9 | |
39 | |
31 | |
8 | |
24 | |
7 | |
21 | |
24 | |
5 | |
30 | |
18 | |
19 | |
16 | |
30 | |
33 | |
16 | |
38 | |
48 | |
26 | |
22 | |
37 | |
81 | |
76 | |
76 | |
85 | |
43 | |
51 | |
72 | |
70 | |
173 | |
168 | |
107 | |
43 | |
64 | |
120 | |
99 | |
6 | |
38 | |
266 | |
201 | |
205 | |
169 | |
303 | |
69 | |
13 | |
53 | |
42 | |
10 | |
48 | |
54 | |
38 | |
18 | |
46 | |
12 | |
38 | |
65 | |
95 | |
60 | |
83 | |
118 | |
43 | |
44 | |
105 | |
77 | |
54 | |
15 | |
76 | |
207 | |
112 | |
336 | |
192 | |
182 | |
168 | |
330 | |
453 | |
551 | |
355 | |
186 | |
218 | |
245 | |
127 | |
223 | |
371 | |
453 | |
373 |
