From 8fbfaa51bb3f583eeebc1239388832b2e966d424 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Thu, 26 Nov 2015 22:20:50 +0100 Subject: gtphub: remove another obsolete comment. --- openbsc/src/gprs/gtphub.c | 69 ----------------------------------------------- 1 file changed, 69 deletions(-) diff --git a/openbsc/src/gprs/gtphub.c b/openbsc/src/gprs/gtphub.c index 95bf7f796..f21eb98dd 100644 --- a/openbsc/src/gprs/gtphub.c +++ b/openbsc/src/gprs/gtphub.c @@ -1017,75 +1017,6 @@ static void gtphub_map_restart_counter(struct gtphub *hub, /* TODO */ } -/* gtphub_map_ie_teis() and gtphub_unmap_header_tei(): - * - * TEI mapping must happen symmetrically. An SGSN contacts gtphub instead of N - * GGSNs, and a GGSN replies to gtphub for N SGSNs. From either end, TEIs may - * collide: two GGSNs picking the same TEIs, or two SGSNs picking the same - * TEIs. Since the opposite side sees the sender address being gtphub's - * address, TEIs among the SGSNs, and among the GGSNs, must not overlap. If a - * peer sends a TEI already sent before from a peer of the same side, gtphub - * replaces it with a TEI not yet seen from that side and remembers the - * mapping. - * - * Consider two SGSNs A and B contacting two GGSNs C and D thru gtphub. - * - * A: Create PDP Ctx, I have TEI 1. - * ---> gtphub: A has TEI 1, sending 1 for C. - * ---> C: gtphub has TEI 1. - * <--- C: Response to TEI 1: I have TEI 11. - * <--- gtphub: ok, telling A: 11. - * A: gtphub's first TEI is 11. (1) - * - * B: Create PDP Ctx, I have TEIs 1. - * ---> gtphub: 1 already taken for C, sending 2 for B. (map) - * ---> C: gtphub also has 2. - * <--- C: Response to TEI 2: I have TEI 12. - * <--- gtphub: ok, TEI 2 is actually B with TEI 1. (unmap) - * B: gtphub's first TEI is 12, as far as I can tell. - * - * Now the second GGSN comes into play: - * - * A: Create PDP Ctx, I have TEI 2. - * ---> gtphub: A also has TEI 2, but for D, sending 1. (2) - * ---> D: gtphub has 1. - * <--- D: Response to TEI 1: I have TEI 11. - * <--- gtphub: from D, 1 is A. 11 already taken by C, sending 13. (3) - * A: gtphub also has TEI 13. (4) - * - * And some messages routed through: - * - * A: message to TEI 11, see (1). - * ---> gtphub: ok, telling C with TEI 11. - * ---> C: I see, 11 means reply with 1. - * <--- C: Response to TEI 1 - * <--- gtphub: 1 from C is actually for A with TEI 1. - * A: ah, my TEI 1, thanks! - * - * A: message to TEI 13, see (4). - * ---> gtphub: ok, but not 13, D wanted TEI 11 instead, see (3). - * ---> D: I see, 11 means reply with 1. - * <--- D: Response to TEI 1 - * <--- gtphub: 1 from D is actually for A with TEI 2, see (2). - * A: ah, my TEI 2, thanks! - * - * What if a GGSN initiates a request: - * - * <--- D: Request to gtphub TEI 1 - * <--- gtphub: 1 from D is for A with 2, see (2). - * A: my TEI 2 means reply with 13. - * ---> gtphub: 13 was D with 11, see (3). - * ---> D: 11 from gtphub: a reply to my request for TEI 1. - * - * Note that usually, it's the sequence numbers that route a response back to - * the requesting peer. Nevertheless, the TEI mappings must be carried out to - * replace the TEIs in the GTP packet that is relayed. - * - * Also note: the TEI in the GTP header is "reversed" from the TEI in the IEs: - * the TEI in the header is used to send something *to* a peer, while the TEI - * in e.g. a Create PDP Context Request's IE is for routing messages *back* - * later. */ - static int gtphub_unmap_header_tei(struct gtphub_peer_port **to_port_p, struct gtphub *hub, struct gtp_packet_desc *p, -- cgit v1.2.3